I've been given the project of developing an intranet web portal for my company using MVC 5. This will be used to replace numerous Access Db front end apps that are currently in use as well as accessing SSRS reports.
My thought is to create a main "portal shell" that handles user logins and security and provides a customizable page where users can select which app (ie: portlets) they want to see and interact with.
Would Areas be an appropriate approach for this project? Add areas to the main shell for each app that returns a partial view to be displayed in that main shell dashboard?
Thanks!
Areas are simply logical organizations of an application. It will still be the same application (running under the same worker process), just properly organized for easier maintenance.
If you want the portlets to be different applications all accessible through a shell, then you may consider hosting them separately and communicating to them from the shell through actual redirects.
Take a look at this SO answer for code samples, both for normal calls and Ajax calls.
This question is likely to get closed as it doesn't fit well with the SO question guidelines.
However, to answer this if you want to keep multiple apps under one url then areas are the way to go.
I'd suggest a a Master/Root layout and a sub layout for each area. You can add a ViewStart to the /Areas/Foo/Views/and use that to set all views to /Areas/Foo/Views/Shared/_Layout.cshtml. That layout can reference your Master layout in your root Views/Shared folder.
Related
When a user logs into the Liferay Portal I want to show a visualization of the list of files that they have access to. This visualization would be done using Javascript, but preferably not inside a portlet, but just being run on the Portal homepage.
I was looking into some of the JSON web service examples, but I was a bit confused on how to invoke some of the Liferay remote services to access the document files from an application that doesn't extend the Liferay portlet class.
Is this possible to do this from outside a portlet or would I need to implement something using URL parameters as referred in one of the Liferay examples? I don't know there is something I'm not understanding here.
EDIT: I want to implement these remote service requests for the visualization inside of a custom theme that I am using. Yet, due to Olaf's recommendation, I will look to see if implementing my visualization and service requests inside of a portlet would be a better solution to my needs.
Yes, it's possible. I'm not sure what you mean with "not inside a portlet, but just being run on the portal homepage" - typically everything that's displayed on the UI is encapsulated within a portlet (well, or within the theme - but for maintainability reasons I'd keep it out of the theme)
You'll need the p_auth token - how to obtain it is part of the documentation that you link (or the surrounding chapters)
If you run into specific problems, please edit your question and list them (and your code). Currently your question reads "Is this possible...?" and the answer to this is "Yes".
I'm currently working on a CMS for meteor (basically a WordPress-like).
I have a simple question about the design of this CMS.
Should I divide my CMS in two application :
-One part for the viewed content (site, template, viewer plugins)
-Another one for the administration part (statistics, web mastering, post and page creation, etc)
Or,
Should I make an all in one application using different routes and security levels.
From my point of view both have pros and cons.
Divide :
Share the CMS between several servers.
Possibility to manage different websites with only one administration application. Looks like a network.
-Using administration without the viewer app.(Headless Drupal)
-Using the full meteor potential for big application.
All in one :
Smaller application, template more adapted to the administration panel.
Easier to handling it.
-Blog oriented.
I'm really interested by your ideas and opinion.
Thanks.
I'd suggest splitting it up between viewers and admin. You don't want viewers of the site to have to download so much extra code. Both parts can share the same database.
I am starting to play with Orchard's multi-tenancy options to enable a single codebase to host dozens of websites (perhaps over a hundred in the future). The pieces I'm unclear on with this are:
Is it possible to call one or more API endpoints to dynamically create these sites from code on my end? Meaning, we have an existing codebase (non-Orchard) in .Net so what API(s) would I call to create these sites on the fly without having to login and do it manually?
In conjunction with #1, are there API(s) for us to create the individual users for the newly created sites that have a pre-configured set of minimal permissions (create content, deal with media, navigation) and blocking others (settings, user management, etc.)? Our client base for this process is not particularly computer savvy so limiting what they can break will go a long way in saving our support staff having to fix stuff they shouldn't be accessing to begin with.
Is there a way to handle SSO within these multi-tenant sites? The difficult part here would be our site relies on Session variables for access (it's a hybrid of classic ASP and .Net that I'm trying to modernize, but have to leave things like Session in for all the old stuff to work)? I'm guessing this would get into building a module, but know that's a rather advanced process so I'm trying to avoid it if possible.
Thanks in advance!
Yes, but Orchard doesn't easily integrate into existing applications. dotNest is an example of Orchard sites being created dynamically: http://dotnest.com/knowledge-base/topics/lombiq-hosting-suite
Yes. Users can be created from code, and you can assign them restricted permissions, the simplest way of doing it being to create a group with that permission set, and to put those users into that group. All of that can be done from code.
Just use oAuth like the rest of the world.
Just forget about integrating Orchard into an existing application. Especially classic ASP ;) Time to move on.
I am making several web applications. What I want to do here is:
Applications should stand alone in IIS using differnt application pool.
There is one main application used solo as front page, allowing log in/out and navigate users to other applications.
I want other applications to use the layout of the main application.
The structure I was thinking was to deploy the main application under root folder of the website and host other applications under it in seperate folder (seperate application and pool). Something like:
IIS
|
|__Main app (web site)
|
|__App1
|
|__App2
However, I just got confused here:
How can I reuse the layout/dll acorss apps/pools without copying them into each application (Maybe it's a silly question)
How can I use MVC3 controller/action feature instead of directly using hard coded <a/> to navigate users to each application. I actually tried it. Looks like the Main app (MVC3) can only recognize controller and view in it's own project.
In summary, what I try to do is: Deploying my applications in the tree sturcture above and let the main app bring views from sub apps and display in main app's frame.
Maybe it's not a good practise, but any suggetion is welcomed!!!
Thanks a lot
It really sounds like you would want to make use of Areas in MVC. This wouldn't allow you to run the nested "applications" in their own App Pool, but it would accomplish everything else you are looking to do (shared layouts, dlls, Html.ActionLink, roles based access to each Area, etc). You can easily share top level navigation across all Areas and have different sub navigation for each. I have a 2 part blog post about using a single layout that is shared across Areas that might give you some help (or ideas).
Single Layout for Areas with ASPX and Razor views (Part 1) - Using the ASPX View Engine
Single Layout for Areas with ASPX and Razor views (Part 2) - Using the Razor View Engine
If you felt that having sub apps in Areas in a single project was too rigid you could also look into using MvcContrib to make your sub apps in Portable Areas and then consume them in your top level app.
I have a rather large project developed on Sharepoint and Project Server, designed as a multi-tier application. I programmatically manage web parts on certain web part pages. According to the choices of the user in one of the web pages, appropriate web parts are added to the web part collection of another web part page. My problem is that I simply do no know where to manage the web parts, should I do it in the BLL and then have the assembly containing the business logic reference the UI assembly where the web parts are? (I need to instantiate the web parts when adding them to the collection, since I do not want to use hard coded strings representing the web part dwp.)
It really depends on what pattern you're using for your BLL and UI layers, and how strictly you want to follow it.
If you're doing a MVP pattern then I'd suggest that you have the Page implementing an interface which has one (or more) of the following options:
A stack which the Presenters to load are added to
A Load_WebPartName event for each web part which then should be called to indicate which webpart(s) need loading
To be strictly MVP you should not reference the following assemblies in your BLL project:
System.Web
Microsoft.SharePoint
Microsoft.SharePoint.*
(All SharePoint assemblies would be in either the Model or UI projects, the BLL is just connecting to the appropriate hocks)
Can you package the web parts as a feature or set of features and then simply manage the feature(s) activation/deactivation through the web part manager class?
Any programmatic massaging of the web part that needs to happen on the appropriate web part page can be handled in the feature receiver, so your manager doesn't need to be so aware of the web part UI.
HTH,
jt
Web parts are generally best managed using the feature/solution framework. You may treat the webpart classes you write as any other web control, and thus a part of the ui layer. I generally keep the information in the xml files (the .webpart or .aspx files) to a minimum. If you are managing them exclusively, you don't really need to use declarative code files at all.
The short answer: webparts are sharepoint specific ui, and should have no knowledge of the business layer.
The short answer is probably "no, you should not do this in the BLL." A purist might argue that while the BLL may rightfully determine what a user can or can't do, it is up to the UI tier to determine the appropriate web parts to be displayed as a result.
For example, the BLL might determine a user's capabilities and expose them as roles, or permissions or something else with domain-related meaning (e.g. timesheet approver role, approve timesheet permission, etc.). These might then be mapped to a set of web parts by the UI tier (e.g. timesheet approval web part). In this way, the BLL effectively determines the users capabilities and the UI tier determines the UI for those capabilities.