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.
Related
The custom app parts in SharePoint add-ins (SharePoint hosted) gives bad performance when adding them into a custom page in the hosted site.
Is there a solution for this problem?
The slow performance is most likely caused by the way the app parts are placed on the SharePoint page - each app part is contained within it's own iFrame which points to the app web. When the page loads, another full HTTP call has to be performed for the content from each app part placed on the page. Unfortunately - this behaviour is a part of the Add-in model and cannot be changed. Source: How to add SharePoint-hosted add-in as an app part
It has it's positives, as it allows to display content from provider-hosted apps in a web-part like manner. The biggest downside is - it treats SharePoint-hosted apps the same way.
To boost the performance I would suggest (if possible) switching to the SharePoint Framework, which is client-side only, doesn't use internal app webs and renders directly inside the page's DOM without being wrapped with any iFrames. Take a look here: Build your first SharePoint client-side web part
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.
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.
When developing in MOSS I would be interested to hear peoples views on whether they choose to wrap functionality in web parts or to create .aspx pages and deploy those to MOSS and how best to make that decision.
Web Parts are reusable across multiple pages. So if I develop a UI that is only usable once, I create .aspx pages. But if I need something that is usable on multiple pages or if I don't know/can't control where it will be deployed to, I create a Web Part.
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.