I currently have:
#Html.EditorFor(model => model.PurchasePrice)
I would like to split this into 2 separate fields separated by a decimal (for price input obviously). But if I do that using basic text boxes I will loose the ability to take advantage of ASP.NET's validation.
Is there a way to do this, in Razor or by using attributes, so that I am able to keep the JS and server-side validation against my Entity model?
I can easily do it somewhere else by creating my own functions within the viewmodel, but I'm new to MVC3 and not entirely sure if that would be the best route or there is a simpler method.
Edit:
This is kind of the direction I am thinking, I do not fully understand how this works.
I set 2 fields, 1 as ppDollar and 1 as ppCents. In the controller I have:
modelname.PurchasePrice = Request["ppDollar"] + Request["ppCent"];
But, I can look at that and tell that's not going to work. So, I guess the question really is how is user input validated against the entity model and how can I better take advantage of the built in functionality?
You can create custom editors for particular types that are rendered by EditorFor. You can find a lot of examples of how to do this online, most of them focusing on a custom DateTime editor but the same idea applies to any type. Just one example from a quick search:
http://buildstarted.com/2010/09/10/overriding-displayfor-and-editorfor-to-create-custom-outputs-for-mvc/
In short, the process is:
Create a partial view template, placed in the Views\Shared\EditorTemplates folder, with the same name as the type (e.g. Decimal.cshtml).
The view should use, as its model, the type you want to display: #inherits System.Web.Mvc.WebViewPage<System.Decimal>
Make the view display whatever you want, using some field naming convention or whatever.
You can also pass HTML attributes via the appropriate EditorFor overload, referenced in your template through the ViewData.ModelMetadata.AdditionalValues property.
One thing to note: once you define an editor template it will be used for every call to EditorFor. You can scope them to a specific controller by moving the EditorTemplates folder into the appropriate view subfolder instead of the shared one.
Related
I'd like to use Nightwatch's Page Objects system for UI components used across our app. Because nightwatch has their own way of reading/initializing them, I don't see a way of properly extending/re-using them.
For example I want an DateInputPageObject for "date fields". It would identify the label, input, date picker, etc.
I'd use it on any page with a date input field.
I would also like to extend page objects. For example, class FooModal extends Modal. The ModalPageObject would define selectors for elements all modals have - the overlay, container, close button, etc.
I can't find any way to do this in nightwatch, is it possible at all?
The problem is not with nightwatch per se as it's just following the basic structure of page object model BUT that is a very good question and it brings out one of the drawbacks of page object model.
Page object model has been around for some time and the problem with that is that it doesn't serve the needs of modern web applications that use component libraries & living style-guides and re-using components.
Personally I found it easier to use a global json file with all the components structured based on their type. e.g. labels, fields, buttons, etc.
I am using EditorTemplates to style all my input fields. Works like a charm, however now I want two themes of EditorTemplates, one for normal forms, and then one for my wizard forms.
I am already using an overloaded Html.BeginWizardForm() around those Html.EditorFor - but how do I make the MVC logic react on being inside Html.BeginWizardForm() ?
EditorTemplates are designed to be somewhat global. You can override them, though, just like any other view, because they are just views. For example, assuming you have something like Views\Shared\EditorTemplates\String.cshtml, you can then create a another view at Views\Foo\EditorTemplates\String.cshtml, and for any action called from FooController, the latter editor template will be used instead of the one from Shared. You might be able to make this work in your scenario if the wizard form is used in a specific controller or area context.
Short of that, though, there's no way to have this occur automatically. Some manual options still exist, though.
You can decorate the properties of the view model used within the context of the wizard with UIHint attributes. For example, assuming the same shared editor template above, you could do something like:
[UIHint("WizardString")]
public string Foo { get; set; }
That would cause it to look for Views\Shared\EditorTemplates\WizardString.cshtml instead.
You can pass the editor template to use in the call to EditorFor:
#Html.EditorFor(m => m.Foo, "WizardString")
All that said, the biggest problem here is that you seem to be violating a pretty core principal of good web design. HTML is about structure, not presentation. CSS is for presentation. As a result, if you want something to look different in a certain context, the correct approach is to apply different CSS. If things are designed well, your HTML shouldn't really have to change.
It seems is as stated by Chris Pratt not possible to have multiple EditorTemplates.
I however found a workaround by extending the MvcForm and created a WizardForm which adds a value to the ViewContext (in my case "wizardContext" => true) and on disposing setting wizardContext => false.
This allows me in the EditorTemplates to add a check for if I am inside or outside the wizardContext, which will propagate through the nested EditorFor, and in this way allow me to have different themes, without having to be specific in EditorFor.
I have been developing MVC 3 applications using Razor. I was wondering how much code would be acceptable in my views. There were situation where I needed to create, instantiate and use an object which wasn't included in the model and using ViewModel would make the model object bloated. Now when I look at some of my views, I find them full of server side codes. What would be the best practice when dealing with such issues?
I was wondering how much code would be acceptable in my views.
If by code you mean C# code then there should be exactly 0 to be precise. On the other hand it is perfectly fine to write HTML markup in your views and call HTML helpers.
There were situation where I needed to create, instantiate and use an
object which wasn't included in the model and using ViewModel would
make the model object bloated
Then it seems that your view model was not adapted to this view (since this view requires additional information). So change this situation by adapting the view model to it and including everything that it needs.
Now when I look at some of my views, I find them full of server side
codes. What would be the best practice when dealing with such issues?
Yes, that's horrible. Simply adapt your view models and refactor this code into your view models or controllers or even write custom HTML helpers.
I am writing a helper class to query my Zenfolio feed, return and display the images. Right now this code is split between a viewmodel and code in my controller. I want to pack it up into a helper class. Would all the code go into the helper or do i still split the code among different class with the helper only responible for generating the html? I have googled but not found an answer to my question.
Within the MVC pattern there is a clear separation between Model (data), View (html) and Controller (what gives the Model to the View).
To answer your question, No. Load your models in your Controller. Display them in your View. Html Helpers should only generate html for your view.
You may want to consider using a DisplayTemplate, which allows you use the same View template for every model of a particular type.
I wouldn't do any data access from the view. This sounds like a good use case for an action, and reusing code via the RenderAction method. You can mark the action as a child action using the [ChildActionOnly] attribute, which ensures it can't be invoked directly from the HTTP request, and return a PartialView result.
HTML helpers should really be used to generate HTML tags from data taken from the ViewData or Model (i.e. your view model in this case).
Data access in an HtmlHelper is only pain.
I've had the misfortune to inherit a project that had ad-hoc SQL placed into the HtmlHelpers by the 2nd developer on a project. The HtmlHelpers were beautifully written by the first developer, and the ad-hoc SQL pretty much nullified all of the time and effort put into having an service oriented architecture, having an ORM (the 2nd level cache became worthless), the unit of work pattern(transactions, worthless), and every aspect of design. Eventually, this 2nd developer had to make larger and larger HtmlHelpers so that different elements could share access to the data.
This was originally done for a display mode, and editing was accomplished through a pile of ugly custom javascript. All told, when the page rendered, it made 600 synchronous calls to the database.
The default scaffolded views generated by ASP.NET MVC 2 contain links such as:
<%: Html.ActionLink("Back to List", "Index") %>
<%: Html.ActionLink("Create New", "Create") %>
These links are perfect if I came to this page from that same root. But for example, if I have Orders and Persons and I navigate to /Orders/Edit/17 via /Persons/Orders/3, then 'back to list' returns me to Orders root not Persons root, where I want to go, because the 'Edit Orders' view only knows about orders. This makes the navigation awkward and breaks the flow..
I want to reuse the same 'Edit Orders' view regardless of where I came from, but I'm not sure how to pass this information.
I know it's possible to pass parameters like /Orders/Edit/17?myparam=myvalue but will this limit my choices later on if I need to pass parameters which indicate Sort/Filter order for grids?
What is the preferred way to pass a return/origin location to my view so that it can render the links properly? Otherwise, how can I call the view differently from the controller?
EDIT:
For a clean solution, see THIS POST
Passing in parameters through the querystring will not really limit you as long as you don't use the same names. There is a size restriction on querystrings, but you'll probably not hit it.
That's basically how I do it. I'm curious to see what others answer.
This functionality seems like something that should have been accounted for in the framework; it seems fairly hacky to have to specify these parameters because you'd have to do so for every level of navigation.
Why? back is something that belongs in browsers, along with history. Its been like that for a while, why should the framework need to handle that?
What you need its not the norm.
Additionally, you are responsible to keep your code dry. You can definitely handle it in a way that all the repetition you have is the name of the function you are calling.