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.
Related
I would like to know. How I can dynamically choose view? I would like to make the PropertyGrid in my application. The PropertyGrid should must change when user selects object. As I understand for this task I have to use a DataTemplate but how I can dynamically create DataTemplate in code? The fact is that I use plug-ins and View and ViewModel for each plugin located in separate dll and so I can't directly write DataTemplate in PropertyesViewModel.
How can I make the edit properties for each plugin using the Propertygrid if I can't use a DataTemplate?
For Catel it doesn't matter in which assemblies the views / view models are located since it uses relative naming conventions. However, if you want to show a custom view based on logic that might reside inside a plugin, I think this is out of scope for Catel.
To solve this issue, you must implement a custom service that can communicate with the plugins and resolve the right view for a selected object. One solution might be naming conventions (if it's a PersonModel, you might want to show the PersonPropertiesView and PersonPropertiesViewModel). However, this must be a custom service.
We've been using the recommended GWT approach of building parts of our application in an MVP manner. The logic we use is based on Google's examples - the Presenter fetches/prepares data and sets it on the View, and the View contains a reference to the Presenter which it calls (e.g. in UiHandlers).
Some parts of the application which we built should be reused in other views. For example - a view which is sometimes the "main view" of a part of the application - can be used inside a pop-up in another part of the application (of course, the views/presenters are initialized differently in this other case, but basically it is the same thing).
What would be the correct approach to do stuff like this? I cannot seem to find a suitable one without resorting to ugly hacky stuff.
For example - if I put the presenter of the reused component inside the main view - it is easy to initialize the reused component, but it is ugly to receive a result back in the main presenter. This can be solved by passing a runnable or creating a custom handler or passing the parent presenter itself to the reused presenter.
All of these approaches don't seem right to me though and seem ugly.
Any ideas/experiences?
What you're describing is a view being able to be controlled by 2 distinct presenters. Abstracting those presenters behind a common API, in the form of an interface, should be enough.
You can also see it as a composite widget being used within two distinct views. The composite widget would then expose events and a public API that both views could wire to their specific presenters.
See Activites and Places,It can help you to desing and structure you app.
https://developers.google.com/web-toolkit/doc/latest/DevGuideMvpActivitiesAndPlaces
.
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.
Zend_Form:: When should be form created in view and not in controller?
option 1 - form created in controller and passed to view (usually used)
controller:
$form=new MyForm();
$this->view->form=$form;
view:
echo $this->form;
option 2 - form created in view directly (looks better to me because form its subpart of view)
view:
$form=new MyForm();
echo $this->form;
Thanks
In short: newer in view.
You may eventually:
create view helper for complex tasks (and call the helper in view $this->getForm()),
or use Model::getForm()
or service::getForm() when you need cross-action forms.
Further explanation:
Because in the ideal case, views contain only HTML, to separate logic from presentation (MVC).
When using TDD, you write tests for logic, never for view scripts, which are only clothes for the variables.
Displaying the form, is not only the form itself, but also checking whether it was submitted or not, checking for validation errors, setting flash messenger variables and much more.
These are too complex tasks for putting them to view scripts.
As a good exercise on separating logic and presentation, I recommend you to take a look at PHPTAL template language, which is a nice alternative to native PHP as a template language used in ZF.
If a form appears in, say, the sidebar of a layout - like a "Subscribe to our mailing list" form - it seems reasonable to allow the view to create/render it on its own, though I'd probably do it within a view helper rather than have any new My_Form() calls in a view script. Why force every controller to deal with it?
As Padraic Brady notes in his online ZF book Surviving the Deep End: "Controllers Are Not The Data Police".
I think the only first variant is correct, because Zend_Form is not presentation entity, but business logic entity. So it's wrong to try to instantiate it in the view. If you want simply display some form just mark up it directly in HTML - this will be much more easier for coder at least.
Think about your team mates, are your designers( or graphical integrators ) programmers too? that approach will break down re-usability, and tasks separation.
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.