In modern web frameworks like Rails and symfony the concept of partial includes or partial views is well documented and recommended.
What I am having trouble with lately is deciding how much design to include in the partial.
It's kind of hard to explain but I want to know what others do when creating a partial and including it in a template. Do you only display the data and position it in the template or do you put all the styling and positioning code in the partial and just include it like so.
I guess my question is, what is your thought process when deciding to create a partial and when do you use it in your own code, and how much do you put into your partial when you decide to use one.
http://www.symfony-project.org/book/1_2/07-Inside-the-View-Layer#Partials
http://api.rubyonrails.org/classes/ActionView/Partials.html
I use partials for pieces of view code that are used in more than one place. If the code is going to be duplicated or re-used in several places, then it is a prime candidate to be DRY'd up and placed into a partial.
As far as styling code, all that should reside in your CSS files
If you're repeating parts of your view code, a partial is a good idea. If the code you're reusing is a little different between your pages, make use of the parameters you can pass the partial.
As for the CSS, I'd suggest keeping it outside your partial/template. If you have a lot of partial specific CSS code, create a "partials" folder under web/css and name the css files to match your partials (If you think the overhead is worth the organization).
I use partials in two cases:
When I need to re-use views
When a view is huge (hundreds of lines), I split it into partials to make it more descriptive and thereby easier to maintain.
Related
I come from an Asp.Net background and I'm evaluating Asp.Net MVC for a new project. I can't see how to structure a large project adequately.
I'm happy with the Model/View/Controller architecture and I'm presently trying to get Areas to work (which seems quite complicated for what it is).
Can you have Areas within Areas?
Can you put Views in dlls?
I really need a starting point here, are there are resources which show how to structure large MVC projects, assume that eventually there will be 100+ views in the project, I don't want them all in the same folder and ideally I'd like sub folders
thanks for any help
Edit:
I can see that each controller maps to a View folder, what I want is something more like this
Areas
Mail
Absence
SimpleAbsenceController.cs
ComplexAbsenceController.cs
Overtime
SimpleOvertimeController.cs
ComplexOvertimeController.cs
Etc
Edit2: Perhaps this is more of a routing question, can I map from:
http://www.mystuff.com/SimpleAbsence/Index
to Mail/Absence/SimpleAbsenceController
Fundamentally I want a way of structuring my project into folders
I hate answering my own question as I feel it undermines the work of others who try to help, at the same time others may look at this later and these really are newbie questions, so...
(this is all from reading Pro ASP.Net MVC5, good book)
I wanted to know how much flexibility there is in Asp.Net MVC with regard to using subfolders or dlls. This answer address the subfolders question.
Answers
You can put controllers where-ever you like in terms of folders on the disk, these are compiled, but...
When you use areas the MapRoute in the AreaRegistration.cs file automatically limits
the routes to the namespace for the area. So if for example you move a controller to an area you -must- change the namespace or methods like Url.Action will fail
Views must stay where they are, so for a controller called Fred there must be this structure:
View
- Fred
- Action1
- Action2
- etc
You can work around all of this using your own routing system, you could probably work around the namespace issue with a custom route, but my view is as a newbie you should work with the system until you know enough to fully understand the consequences of breaking the rules
So this means you could have a large project with a few hundred Views all lumped together in one folder. It's not quite as bad as it seems as the controllers can be in sub folders and you can directly map from them to the Views.
You also have flexibility in the routing system, so regardless where controller are on disk you can have any urls you like!
e.g. this route maps from
http://www.example.com/App/DoSomething to
http://www.example.com/Home/Something with no changes necessary
routes.MapRoute("NewRoute", "App/Do{action}", new { controller = "Home" });
NB If you do this make sure to use Html.ActionLink or Url.Action (or equivilents) as opposed to direct links, these are clever enough to generate the correct urls based on the routing.
As I say, complete newbie issues but I'm sure others will have the same questions, thanks to MiniRagnarok for his example of a real life project
What we're talking about here is very opinion based. I've seen people that prefer to have lots of Controllers with a mapping of every object to a Controller. I've also seen people that prefer to have tons of Views. So my example is what our team has decided to do and not necessarily the same as you would see in sample tutorials.
Take a project we did that has 200+ Views for example. The site is an auction and retail site.
Controllers
AccountController.cs
AdminController.cs
AuctionController.cs
HomeController.cs
PhotoController.cs
StoreController.cs
SupportController.cs
Views
Account
DisplayTemplates
EditorTemplates
ChangePassword.cshtml
_Favorites.cshtml
Settings.cshtml
Admin
Auction
Home
Photo
Shared
Store
Support
For us, we name all partial views with an underscore first. We also utilize DisplayTemplates and EditorTemplates. All of this really helps us keep things separate. You'll notice that our controllers are split by role or function. We were never bothered by the fact that there are many ActionResults within our controller since all of our logic is really in the models.
In Rails why would I ever use partials? Explain it as if I'm 5 years old. I simply do not get why anyone would ever use them.
First thing, Please have a read here Official Rails guide for partials .
Now some benefits
It keeps your view clean and systematic, DRY Philosphy .
The most important where
partial comes into picture is when you want to reuse some of the
component amongst various view. Usually developer create a kind of
shared/common folder where partial sits and are used amongst
various view.
It’s also easy to conditionally load partials using Rails’ “if” or “unless” statements
It is beneficial where a template needs to iterate over a collection and render a sub template for each of the elements.
Your different partials can also have different layouts.
The Partial API here list all the various methods which will make you understand it's benefit.
Separating your view into partials can also help in in proper fragment caching (Fragment Caching) of some portion of you webpage. Better management.
If you are into Metaprogramming then you can add that flavor in your partials too, by creating dynamic helpers. As Stackoverflow answer here
They are a handy way to avoid repeating yourself.
For example, you may have several pages that display a menu. Instead of repeating the markup for the menu in every view, you just throw it in a partial and render on every page.
There are other cases where complex views are made more manageable by breaking them into several partials.
You normally use partials to reuse code: let's say you have a list of posts and each post has a small preview with image, title and excerpt. In your blog homepage you have a list of posts, when you group posts by year, you show a list of posts, when you search for a term you have to display a list of posts.
Instead of repeating the logic to display a post preview, you can move that logic to a partial and keep referring to that whenever you need it. You can keep your code DRY and write less code. Moreover, if you realize you want to add something new, you can just change the partial instead of going and hunting for the templates which display the post previews all over your application.
Well, for the exact same reason that you want to use methods, which is reusing code. Say you have a status area in your application, that you want to show in different places. You can just put the view code for that status area in a partial and then use that partial on the corresponding pages.
Since partials can also take parameters, they make it very easy to reuse view code. Also, you can make partials dedicated for certain models of your application. This way, you can just call render #model and the correct partial is picked by naming conventions.
A partial allows you to separate layout code out into a file which will be reused throughout the layout and/or multiple other layouts.
For example, you might have a login form that you want to display on 10 different pages on your site. Rather than writing the form code 10 times, you can write it once in a partial, and in each of the 10 pages, simply include that partial at the appropriate place in the layout. If necessary, you can pass local instance variables to the partial to make them available to it.
That way, if you need to change the form, you only need to change the code in the partial, one time, rather than changing it 10 times across all of your layouts.
Here is the guide on partials: http://guides.rubyonrails.org/layouts_and_rendering.html#using-partials
And more discussion on getting data/variables into partials: Pass a variable into a partial, rails 3?
So I am an old web forms guy and new to the MVC (in general, not only ASP.NET) framework. My views are starting to look a lot like the good old classic ASP. Not that i'm adding any business logic or anything, but more of a presentation logic. I end up with a lot of <% %> tags and if/else statements for deciding links to display or styles to use.
I also thought of deciding the styles or links within the controller and setting them on the model, but sounds like breaking the MVC purpose.
I end up ignoring the <% %> to make sure my HTML is well formed.
I want to hear your opinion. Are your views the same as mine? Am I doing something wrong?
If I have a ton of presentation logic, I try to move that to an extension off the HtmlHelper class.
Along with what mxmissle said (I voted him up) says I will do a partial view to move complex areas of a page to a seperate file, it helps clean things up as well as code reuse.
I find if things are looking a bit too old school ASP it's time to refactor. It's surprising what you can clean up into a helper class or partial view, or simply redo using something more concise.
Edit: Also, if it's looking a bit too old school ASP, perhaps you have logic in your view that doesn't belong there.
I usually create a ViewModel class specific for each view that contains any logic associated with the specific view. This is good for situations where the outcome of a condition is just a simple DIV or SPAN tag which don't really warrant their own extension or partial view.
I find it will clean up a lot of the classic ASP'ish look in my views.
See Stephen Walther's blog for more info on this approach.
Yes, you're doing it right. ASP.NET MVC isn't an improvement over classic web forms in every respect. It has its advantages and disadvantages ("tag soup", as you've discovered, being one of the disadvantages).
There are a few ways to alleviate the pain (moving as much logic into the model, HTML helpers, partial views, etc.), but it's difficult to avoid.
Which way do you prefer to create your forms in MVC?
<% Html.Form() { %>
<% } %>
Or
<form action="<%= Url.Action("ManageImage", "UserAccount") %>" method="post">
</form>
I understand that Html.Form() as of PR5 now just uses the URL provided by the request. However something about that doesn't sit well with me, especially since I will be getting all the baggage of any querystrings that are included.
What is your take?
The second way, definitely. The first way is programmer-centric, which is not what the V part of MVC is about. The second way is more designer centric, only binding to the model where it is necessary, leaving the HTML as natural as possible.
On the whole, I think I'm kinda old-school as I prefer to roll my own HTML elements.
I also prefer a view engine like like NHaml, which makes writing HTML almost an order of magnitude simpler.
I have to agree with both of you, I am not really like this simplistic WebForms style that seems to be integrating its way in to MVC. This stuff almost seems like it should be a 3rd party library or at the very least an extensions library that can be included if needed or wanted.
I am totally in the opinion of old school HTML, that is what designers use. I don't like to include to much code centric syntax for this reason. I treat the web form view engine like a third party library, because I replaced it with a different view engine. If you do not like the way the web form view model works or the direction it is going, you can always go a different route. That is one of the main reasons I love ASP.NET MVC.
I agree with Andrew Peters, DRY. It should also be pointed out that you can specify your controller, action, and params to the .Form() helper and if they fit into your routing rules then no query string parameters will be used.
I also understand what Will was saying about the V in MVC. In my opinion I do not think it is a problem to put code in the view as long as it is for the view. It is really easy to cross the line between controller and view if you are not careful. Personally I can not stand to use C# as a template engine without my eyes bleeding or getting the urge to murder someone. This helps me keep my logic separated, controller logic in C#, view logic in brail.
The reason for using helpers is that they allow you to encapsulate common patterns in a consistent and DRY fashion. Think of them as a way of refactoring views to remove duplication just as you would with regular code.
For example, I blogged about some RESTful NHaml helpers that can build urls based on a model.
What is the purpose of the code behind view file in ASP.NET MVC besides setting of the generic parameter of ViewPage ?
Here's my list of reasons why code-behind can be useful taken from my own post. I'm sure there are many more.
Databinding legacy ASP.NET controls - if an alternative is not available or a temporary solution is needed.
View logic that requires recursion to create some kind of nested or hierarchical HTML.
View logic that uses temporary variables. I refuse to define local variables in my tag soup! I'd want them as properties on the view class at the very least.
Logic that is specific only to one view or model and does not belong to an HtmlHelper. As a side note I don't think an HtmlHelper should know about any 'Model' classes. Its fine if it knows about the classes defined inside a model (such as IEnumerable, but I dont think for instance you should ever have an HtmlHelper that takes a ProductModel.
HtmlHelper methods end up becoming visible from ALL your views when you type Html+dot and i really want to minimize this list as much as possible.
What if I want to write code that uses HtmlGenericControl and other classes in that namespace to generate my HTML in an object oriented way (or I have existing code that does that that I want to port).
What if I'm planning on using a different view engine in future. I might want to keep some of the logic aside from the tag soup to make it easier to reuse later.
What if I want to be able to rename my Model classes and have it automatically refactor my view without having to go to the view.aspx and change the class name.
What if I'm coordinating with an HTML designer who I don't trust to not mess up the 'tag soup' and want to write anythin beyond very basic looping in the .aspx.cs file.
If you want to sort the data based upon the view's default sort option. I really dont think the controller should be sorting data for you if you have multiple sorting options accessible only from the view.
You actually want to debug the view logic in code that actuallky looks like .cs and not HTML.
You want to write code that may be factored out later and reused elsewhere - you're just not sure yet.
You want to prototype what may become a new HtmlHelper but you haven't yet decided whether its generic enough or not to warrant creating an HtmlHelper. (basically same as previous point)
You want to create a helper method to render a partial view, but need to create a model for it by plucking data out of the main page's view and creating a model for the partial control which is based on the current loop iteration.
You believe that programming complex logic IN A SINGLE FUNCTION is an out of date and unmaintainable practice.
You did it before RC1 and didn't run into any problems !!
Yes! Some views should not need codebehind at all.
Yes! It sucks to get a stupid .designer file created in addition to .cs file.
Yes! Its kind of annoying to get those little + signs next to each view.
BUT - It's really not that hard to NOT put data access logic in the code-behind.
They are most certainly NOT evil.
Ultimately, the question you ask yourself is this:
Does this code A) Process, store, retrieve, perform operations on or analyze the data, or B) Help to display the data?
If the answer is A, it belongs in your controller. If the answer is B, then it belongs in the view.
If B, it ultimately becomes a question of style. If you have some rather long conditional operations for trying to figure out if you display something to the user, then you might hide those conditional operations in the code behind in a Property. Otherwise, it seems like most people drop the code in-line to the front end using the <% %> and <%= %> tags.
Originally, I put all my display logic inside the <% %> tags. But recently I've taken to putting anything messy (such as a lengthy conditional) in my code behind to keep my XHML clean. The trick here is discipline - it's all too tempting to start writing business logic in the code behind, which is exactly what you should not be doing in MVC.
If you're trying to move from traditional ASP.NET to ASP.NET MVC, you might aviod the code behinds until you have a feel for the practices (though it still doesn't stop you from putting business logic inside the <% %>.
There isn't a purpose. Just don't use it except for setting the model
ViewPage<Model>
See this blogpost for more info.
At this Blogpost is a working example of removing the code behind.
The only problem I'm stuck with is that it is not able to set namespaces on the class.
The codebehind provides some of the strong typing as well as the intellisense support that you get in the view. If you don't care about any of these two features, you can remove it.
For example, I typically use the NVelocity ViewEngine because it's clean and pretty straight forward.
This is a great question. Doesn't MVC exist in the ASP.NET environment, without using the specific MVC pattern.
View = aspx
Controller = aspx.cs (codebehind)
Model = POCO (Plain Old C#/VB/.NET objects)
I'm wondering why the added functionality of MVC framework is helpful. I worked significantly with Java nd MVC and Java Struts several years ago (2001), and found the concepts in MVC to be a solution for the Internet Application organization and development problems at that time, but then found that the codebehind simplified the controller concept and was quicker to develop and communicate to others. I am sure others disagree with me, and I am open to other ideas. The biggest value I see to MVC is the front controller pattern for Internet development, single entry source for Internet Application. But, on the other hand, that pattern is fairly simple to implement with current ASP.NET technologies. I have heard others say that Unit Testing is the reasoning. I can understand that also, we used JUnit with our MVC framework in 2001; but I have not been convinced that it simplifies testing to use te MVC framework.
Thanks for reading!