I am going to create new Financial web application using Asp.net MVC fully ajax, hosted on customer intranet.
i have Company setup screen,
Company Model is shown Below.
Company {Main Company info, Bank info}
.|_Regions - each :{Region info, Contacts}
...|_Districts - each : {district info,Contacts}
.....|_Branches - each : {branch info, contacts}
I thought to make it master/detail , master/detail, master/detail in one page, another idea to make master/detail for company then tabs for region,district and branch and make each tab dependent on previous one. i don't like both ideas, it is very difficult for user to understand the page layout, in addition it is very old style.
the problem is all application pages follow this pattern.
I need smart idea for page layout fit with nested model like this example , i prefer if it is inspired by IPad or mobile apps designs.
thanks
Related
I'm building a large hierarchical web application and I need some help deciding on some best practices with leveraging MVC.
The application will have tabs at the top which control a sub page, and a query pane (off to the side).
There will be two templates for query panes, each used by different sub-pages. The sub-pages will be based on the selected tab with settings derived from the query panes.
Clicking on tabs or updating the query pane will update the sub-page section without refreshing the page.
I'm a bit new to MVC and what I don't quite understand is how I can leverage MVC methodologies to help me manage the web application's state (which consists of the selected tab, query options, and other page-specific options).
Currently I'm planning on initially setting up a model which stores the client state parameters (default values, or values obtained from a DB), and using it to load the page, consisting of several partial views. When anything is changed (tab/query/etc), the view will call a corresponding controller, passing back model parameters via post (I'm assuming there's no way to store session-specific client state models on the server-side?).
My question is:
Am I doing it right?
If not, what am I missing; and specifically, is there a way to store these session-specific state models server side so they don't have to be passed back to the server during every single page transaction?
If I understood everything you need Its a SPA (Single Page Application). This will provide a magic user experience, without full page reload, and low data traffic. But, requireds some MVVM framework (AngularJS, KnockoutJs, etc) and a lot of JavaScript coding. But the result is amazing. The guy behind this in MVC is John Papa, take a look in everything on his blog and you will win.
John Papa Blog
Hopes Its Help you
I come from ASP.NET Form development and now developing a MVC 3.0 application where when customer logs in she can select her different account from drop down:
The drop down contains:
Honda Car Insurance Account
Home Insurance Account
Ford Car Insurance Account.
When she selects one of the account the landing page changes with her historical details data etc. The application contains 4 more pages which has different contents for each account types.
In ASP.NET Form we could use themes and skins etc to apply the styles on the page based on which account the user has selected. However I don't see this seem to work on MVC.
Could anyone please suggest what would be the best way to achieve above in MVC?
Create one controller for each page and separarate views fro each accounts?
Should each page contentes be served by partial views?
Any other suggests?
NB: The JSON structure sent from controller is unique to each account type as each account have different properties.
Thank you very much for your help.
I would use a separate controller for each section. Then in the View folder for that controller, add a _ViewStart.cshtml file and inside it put
#{
Layout = "~/Views/Honda/_Layout.cshtml";
}
This will point to the layout page for this controller (Honda controller, but use whatever names you want.)
Then in the _Layout files you can add different layouts, css, etc.
That's probably the simplest way to get drastically different looking sections to the same site. Plus you would still have your default Home and Account controllers to keep a standard landing page, etc.
You can still use partial views, and anything else you would like with this setup. It may even mean faster loading time for the end user since their browser won't have to download css and other files that it's not using.
Edit
Here is a bit more information, ASP.NET MVC 3: Layouts with Razor from ScottGu's Blog
Because this code executes at the start of each View, we no longer
need to explicitly set the Layout in any of our individual view files
(except if we wanted to override the default value above).
Important: Because the _ViewStart.cshtml allows us to write code, we
can optionally make our Layout selection logic richer than just a
basic property set. For example: we could vary the Layout template
that we use depending on what type of device is accessing the site –
and have a phone or tablet optimized layout for those devices, and a
desktop optimized layout for PCs/Laptops. Or if we were building a
CMS system or common shared app that is used across multiple customers
we could select different layouts to use depending on the customer (or
their role) when accessing the site.
This enables a lot of UI flexibility. It also allows you to more
easily write view logic once, and avoid repeating it in multiple
places.
I am a little ashamed for asking so many questions, but I really want to learn.
In Sipke's blog a webshop is created. There is one specific question that boggles my mind when trying to do something similar.
Let me spell out the basic requirements:
User registration form and login, etc. This one is covered by the blog and it works nice.
Creating product parts and so on. This one is covered and no problem there.
Ordering by filling in an order form and making the payment. See down
Having the order page maintainable by customer. See down.
Viewing your own orders and their status. See down
Maintaining customers and orders from backend system. This one is covered by the blog and I need to do some work there yet.
As for items regarding creating orders and viewing your orders. I have followed the approach for creating records and using standard MVC controllers. But then I encountered problems:
Menu for orders page. This I had to do manually after installing the module.
The order page itself. I had to create the view including title and so on. But I can imagine a customer wanting the order page on another menu and with a different title. And maybe add even some own content to the ordering page. This I couldn't achieve by using standard MVC approach. So maybe I am using the wrong approach here. So I was thinking about using contentparts for creating an order and displaying them and using the drivers and handlers for that. But before I go down that road and refactor everything I want to know if that is the right approach. A downside could be that once the module follows that route it can then not so easily be reused with customers that have other cms's capable of hosting an MVC3 module.
So when to use drivers, handlers and contentparts and when to use standard controllers and views.
You should use Drivers and Parts (with Handlers if needed) when you want to create functionality for content items. E.g. if you want to display a custom media with all products, you could create a Part (together with its Driver, etc.) to handle that. Read the docs on Parts.
If the functionality is not tied to content items the most possibly you want to use the standard MVC toolbox, it's fine. Look at the built-in modules how they do that. E.g. the Blog module uses controllers and views to show the admin UI, but has parts to enhance the functionality of for example the Blog content type.
To make things more complicated you can employ ad-hoc content items to build a page that you'd normally do with simple views, but that's an advanced topic :-).
I have a question about how to design my controllers properly.
Project is fairly simple: blog, immage gallery with categories and images inside them, news secion.
However I don't know how to organize my controllers for this because I want to make somewhat admin panel where administrators can edit, add and modify these things. I've came up with 3 scenariosu so far...
Admin panel will have links to site/controller/edit, but layout for these action results will be different from standard one.
Admin controller will have all these actions like BlogAdd, BlogEdit so that url will be something like /site/admin/blogedit.
Create copies of Blog controller in admin folder so url will be like /site/admin/blog/edit - i sense problems with routing since 2 controllers with same name does not sound like a good idea, however I like ho URL looks in this situation.
What I'm trying to make is CMS somewhat similar to wordpress, where blog creation,editing and deletion is completely separated from default blog itself.
I suggest you stop thinking about URLs and Controllers being a 1->1 relationship. This will make things MUCH easier and less confusing. You can make the URLs work however you want with MVC's routing mechanism and there's no reason to restrict your controller design/organization because of the URLs you want, because you can always adapt the routing to with with the URLs you have in mind.
While building the website, just focus on the controllers (and the general interface) and ignore the URLs until you get to that point, and then when you come up with a good URL scheme go into the routing system and add the routes to connect to your existing controller actions as you want.
Once you code out your blogging engine you will have a much better idea of the user workflow and will probably find different ways to organize your URLs, and you can then reorganize your URLs without touching the controllers themselves.
As to your first requirement:
There are two ways to do this depending on your end goal. If your goal is to display the same core content, but have different user options available (different overall layout, additional buttons on the page, etc..) then the best idea is really to just pass in an IsAdministrator property in your view model, and make the slight changes to the page based on if that's true or false. The reason is because you still (most likely) want the core of the page to be the same, and this keeps you from duplicating code that is related to the core data (data that's being displayed for both admins and non-admins).
Edit: So in summary, organize your controllers based on what makes it easier to develop with, not based on how the user interacts with the system with. You can always change the latter, changing the former is harder and will make maintenance annoying.
You can create Areas in your MVC project and have your admin functionality in a controller in your admin area.
This will allow you to easily seperate your administration functionality from your general blog functionality.
That's how I'd do it.
Why don't you keep the routes the same and handle the different roles via security? For example:
/blog/name-of-topic/view to view a topic (all users)
/blog/name-of-topic/edit to edit a topic (only enabled for logged in users)
/blog/add to create new topics (only enabled for logged in users)
You can handle these actions in a single controller and decorate the actions that require logged users via the [Authorize] attribute. Same thing with the links on your views, you would enable the links to edit and add topics only to visible users.
You could still have a separate panel to allow admins to hit the aforementioned add/edit links .
I have an MVC application that among other things contains a small Silverlight menu that is displayed as part of the .Master page used in most pages.
I have also written a MembershipProvider (and a role provider) that uses my app's database for authenticating and authorizing users. Works fine.
However, I want the Silverlight menu to contain some extra items if the user is in the admin role. Of course one possibility is to make two Silverlight menu applications and choose which one to display based on the user in the master page. But this has a ring of ugly to me.
The better option would be if the Silverlight app could figure out the identity of the logged in user is and use it to configure itself to show the admin options.
Is there a simple way to do something like this? The MVC application and the Silverlight app(s) are deployed on the same IIS7 server and part of the same solution.
The solutions I have found on the web so far either prompt the user for a separate login inside the Silverlight application, or do a lot of work with WCF services. If I have to, I'll go that route, but I am stuck with a feeling that there should be an elegant, easy way to do this.
I believe firmly in the KISS principle so simplicity is highly appreciated!
Thanks!
I'm pretty much convinced that your Silverlight menu shouldn't have to be aware of whether the user is an admin or not.
If you have a "generic style" menu control that can display any number of items, then I think those items should be communicated. The master view should then decide the items to show. Better yet, a controller should return the items to show based on the user's status and the master view should just render them.
If you have a menu control designed specifically to fit in your web app that isn't really made to show any number of items, then the master view should just set a property or something to communicate this fact.
The rest of your question confused me a bit, but I'm convinced that your silverlight component is not a complete "app" in its own right, just a piece of the presentation.