Having worked with .net in both winforms and ASP.net for a few years I am now starting to get into MVC (a little late I know). One major confusion for me is the concept of reusable 'components', similar to the concept of a usercontrol in webforms.
For example, I would like to have a number of 'widgets' within the members area of my site, one of which is the details of the logged in users account manager. I can create this as a partial however when the page loads the data needs to be passed in as part of the ViewModel / View Data. I would like to use this widget in a number of different sections which would then mean that I need to put the code to pass the data in into a number of different controllers. This seems to violate the DRY principle, or am I missing something here? I would ideally like everything to be encapsulated within the 1 partial which can then be used in any page.
You can go three ways:
1) For simple controls without much logic, you can create new instance of the custom view model for the control:
Html.RenderPartial("YourControl", new YourControlViewModel () { Param1="value1", Param2 = Model.AnotherValue });
2) If you need some back end logic for the control, you can use
Html.RenderAction("ActionName", "SomeControllerName", RouteValuesDictionary);
It will call standard controller action, use the view, and insert the resulting output back to the page. You can add [ChildActionOnly] atribute to the controller method to ensure that the method will be available only from the Html.RenderPartial. It is slightly violating the MVC principle (view shouldn't call controller), but its great for widgets, and it is used in the Ruby on Rails world without much issues. You can check great article from Haacked
3) Create custom html helper for tasks like custom date formatting, calculating etc..
In your case, I would choose the number two.
Related
I would like to know what is the best method to have an action return different views. Let's say you have a form for submitting data, but you want to choose the view depending on what data is submitted. I would prefer not using a redirection, since there is stuff I want to be displayed in the data that is posted.
An example of this would be to have an Edit form that displays a Details view when clicking on Save, but without using a redirection.
I know this could be done with a single view containing a conditional if statement to display this or that, but there are cases where I would prefer my views to stay simple without too much code in them. If the controller could just choose the view to display once the data is posted, this would be great.
There is an overload to the View() method that allows you to specify the name of the View you want to return.
return View("DetailsView", model);
You should be using the Post/Redirect/Get pattern. You can still "display stuff." You can pass an ID on the URI and look them up in the new GET or use TempData.
Attempting to circumvent Post/Redirect/Get is not a good solution. Among other things, it breaks the back button.
I`m using asp.net mvc 2.0 and trying to create reusable web site parts, that can be added at any page dynamically.
The problem I have is how to load a partial view with all related js and data? Ive tried the following ways to do that:
Use partial view and put all the js into it. In main view use render partial. But to initialize partial view I need to add model to current action method model to be able to make RenderPartial("MyPartialView", Model.PartialViewModel).
Also I do not have a place to put additional data I need to fill my form(like drop down lists values, some predefined values etc).
Use RenderAction, but it seems it have same problems as RenderPartial, except for I do not need to add anything to any other model.
Any other oprions are greatly appreciated.
As I understand it, RenderAction performs the full pipeline on the action, then renders the result - so what is rendered is the same as what you'd see if you'd browsed to the action.
I've used RenderAction to render 'widgets' throughout a site, but in my view they should be independent of the page rendering them, otherwise they're not really widgets and should be part of the rendering page's code instead. For instance, if there's a log in form, you will always take the user to a page that can process the information, no matter what page they are currently on, so this makes for a good widget. Other ways I've used it is to show a shopping basket or advertising. Neither of which are dependent on the page being shown.
Hope this helps a little!
I have a layout which works fine. This layout contains several partials, which display adverts, a side column a slideshow, etc. All of these are likely to change depending on which page (module/controller/action) of the site you are on.
What is the best way of doing this correctly? In the past I have assigned variables to my view inside my controllers, these are then passed to the partial which then displays the correct slideshow or advert. This seems ugly and not entirely correct for an MVC application.
Does anyone have any other methods of doing this?
Partials are just another view scripts.
My advice is: newer put your logic into the view scripts. Your may store the logic in:
models (remember, that you can create your own models, extending, or not extending the basic database models, eg. data hydrators)
view helpers (with parameters)
services (dependent on models, returning models)
combination of the above
Then use view helper or pass the ready data (model) to different partials.
Tip: Dependency injection is a good thing.
I've made an Area project for my ASP.NET MVC application called 'Admin'.
This will contain all the logic for the Administration section of the site, where the users can add/remove pages, etc.
There's a menu at the top, of things the user can manage. (E.g. 'Content', 'Users', etc)
For each of these, I'm making a controller ('ContentController', 'UsersController', etc)
I'm wondering how to setup the navigation, as there seem to be varying approaches.
One approach is to use MvcSiteMap, which involves creating a '.sitemap' file and decorating actions on my controllers with an 'MvcSiteMapNode' attribute.
The problem with the above is that it's complicated to implement (especially in an Area project, because of the way Areas work in ASP.NET MVC). It also seems like overkill.
I've come up with a different way, which is to decorate each controller with my own attribute. Then I have a helper method that renders my navigation by using reflection to loop through every controller, pick out the ones that have that attribute, and then add them to the navigation menu.
What are your thoughts on the above method? Can you think of an even simpler way of doing this?
So I've done it my way - an attribute on each controller, then a static method that reads all the attributes on application start (using reflection) and keeps them in memory.
So far this has worked perfectly, and I haven't needed any of the advanced features of MvcSiteMap.
I'm a beginner with Eclipse RCP and I'm trying to build an application for myself to give it a go. I'm confused about how one actually goes about handling model objects. None of the examples I can find deal with the problem I'm having, so I suspect I'm going about it the wrong way.
Say I need to initialise the application with a class that holds authenticated user info. I used my WorkbenchWindowAdvisor (wrong place?) to perform some initialisation (e.g. authentication) to decide what view to show. Once that's done, a view is shown. Now, that view also needs access to the user info I had earlier retrieved/produced.
The question is, how is that view supposed to get that data? The view is wired up in the plugin.xml. I don't see any way I can give the data to the view. So I assume the view has to retrieve it somehow. But what's the proper place for it to retrieve it from? I thought of putting static variables in the IApplication implementation, but that felt wrong. Any advice or pointers much appreciated. Thanks.
The problem you are facing here is in my opinion not RCP related. Its more an architectural problem. Your view is wired with business logicand!
The solution can be done by two (common) design-patterns:
Model-View-Controler (MVC)
Model-View-Presenter (MVP)
You can find plenty information about this in the web. I am going to point a possible solution for your particular problem using MVP.
You will need to create several projects. One is of course an RCP plugin, lets call it rcp.view. Now you create another one, which doesnt make UI contributions (only org.eclipse.core.runtime to start with) and call it rcp.presenter. To simplify things, this plugin will also be the model for now.
Next steps:
Add the rcp.presenter to the
dependencies of rcp.view (its
important that the presenter has no
reference to the view)
Export all packages that you are
going to create in the rcp.presenter
so they are visible
In rcp.presenter create an interface
IPerspective that has some methods
like (showLogiDialog(), showAdministratorViews(User user), showStandardViews(User user))
Create a class PerspectivePresenter that takes IPerspective in the constructor and saves it in an attribute
In rcp.view go to your Perspective, implement your interface IPerspective, and in the constructor create a new reference presenter = new PerspectivePresenter(this)
call presenter.load() and implenent
this in the presenter maybe like this
code:
public void load()
{
User user = view.showLoginDialog(); // returns a user with the provided name/pw
user.login(); // login to system/database
if(user.isAdministrator())
view.showAdministratorViews(user);
else
view.showStandardViews(user);
}
As you can see, the view just creates a reference to the presenter, which is responsible for all the business logic, and the presenter tells the view what to display. So in your Perspective you implement those interface functions and in each one you can set up your Perspective in a different way.
For each View it goes in the same way, you will need a presenter for the view which performs operations and tells the view (using the interface) what to display and passing down the final data. The view doesnt care about the logic. This is also very usefull when using JFace-Databindings (then only bound data is passed to the view).
For example, the WorkbenchWindowAdisor will just create everything that is needed in the application. Other views, perspectives, then can enable/disable menus and so on depending on the data they got (like when isAdministrator you might want to enable an special adminMenu).
I know this is quite a heavy approach, but the Eclipse RCP is designed for big (as the name says rich) applications. So you should spend some time in the right architecture. My first RCP app was like you described...I never knew where to store things and how to handle all the references. At my work I learned about MVP (and I am still learning). It takes a while to understand the concept but its worth it.
You might want to look at my second post at this question to get another idea on how you could structure your plugins.