Durandal and multiple views using the same vm - view

I have an ADD and an EDIT page for a customer entity. The data to support each function is similar, however there are business rules that differ between the 2, and slightly different UI, so my original thinking is that I make 2 separate views, but use a single vm. This is a different approach than the John Papa example I'm using as my guide, as he had a separate vm for each. (sessionadd.js, sessiondetail.js). The data is identical so it seems like a lot of duplication, but maybe that's the way to go.
Two questions: what is the best practice in this scenario where the data for an add/edit is the same, but the rules are different? I can already see myself doing "if (mode == 'add'){ // stuff } else {// its an edit }. That bothers me a little, but I also don't like the idea of having to change 2 vms if I add a new field to the views.
Second question, can I specify the view as part of the route definition? I didn't see anything in the docs but I'm still new to the framework. In the following routes, I would like the first one to be loaded with custedit.html and in the second one custadd.html. Both using the custmaint.js vm (never at the same time tho).
{ route: 'custedit', moduleId: 'viewmodels/custmaint', title: 'Edit' },
{ route: 'custadd', moduleId: 'viewmodels/custmaint', title: 'Add' },
thanks

You can customize the view you want to be used by defining getView() or viewUrl() on your viewmodel as described here:
http://durandaljs.com/documentation/Hooking-Lifecycle-Callbacks.html
As to your initial question, if they are very similar, I would definitely combine edit and add operations within a single viewmodel and single view. Sharing the same viewmodel but splitting the views will likely result in a ton of duplicated view code. You could always decompose the elements of your view into smaller views if you need to simplify.
If the edit and add experience are different enough to warrant a separate view, I would create a separate viewmodel as well (and potentially look into splitting view parts and viewmodel functionality into smaller components)

Related

Override EditorTemplate based on BeginForm

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.

How can I take better advantage of Entity Model validation?

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.

Backbonejs: updating subviews and views when needed upon route navigation

we have a small questionaire application,
and 1 of the main sections is the questionaire itself.
it has a big view for some general templating, introduction and title etc
and it has subviews per question (with next and previous buttons)
we decided to use routing, because from several places one can jump to a specific question
so we use /ivr/4 to show question 4, and /ivr/overview showing the final overview.
so in a way you go from /ivr/1 to /ivr/2 ... to /ivr/overview
now, if one comes from /ivr/1 and arrives on /ivr/2
the big view is there, and it should only update the question to the right question
but when you arrive from /home to /ivr/2
the big view is not loaded, so one should first open the questionaire and then load question 2
currently i have it always rerendering the big view
which works, but is lots of overhead and i would like to refactor this to a better way.
can anyone give me some guidance as to how i would structure routeActions and or views
to only update the big parentview when it actually needs to, and do the question view only, if the parent view is already there.
do i need events?
or would i go with partial routes?
any tip is welcome.
I think both of your proposed solutions sound workable. If you go with events, I'd recommend using the event aggregator pattern to facilitate communication between your views. This seems like the simpler option to me.
The other solution, partial routes, might be more involved. Check out the Backbone.Marionette plugin, which was designed to help manage complex view manipulation.

How do you design a text-based view using Ember.js or some other MVC javascript framework?

I have an homemade javascript which, among other things, do some kind of text-formatting work in order to emulate a retro text-based game:
When developing it, i tried to stick close to an MVC model, and this is what i did:
The data model basically consists of a list of objects mapping strings to very specific locations in the display, like this
[{
"value":"Hello!",
"color":"blue",
"row":1,
"column":13
},
{
"value":"What is your quest ?",
"color":"red",
"row":5,
"column":10
},
/* ... some other data */]
Then my view consists of a simple <pre> tag. When my controller draws the model on the view, it iterates through each string-location pair and create a <span> for each one that is appended to the <pre> tag. To keep the formatting consistent, it also adds "blanck" span each time it is needed.
<pre>
<span> </span><span class="blue">Hello!</span><span> </span><br>
<!-- ... other lines of the scene-->
</pre>
It's pretty simple, but it worked great until i had to dynamically change a span text value, without redrawing the whole scene each time.
So i took a look on the internet and realized that Ember.js existed, it really seems to be exactly what i could use to improve my whole code.
Now, i tried to redesign it using Ember.js, but as i don't fully understand yet its features i ran into a problem:
How do you represent a 'text-based' view into an Ember.js handlebar template ?
What am i missing here?
My data model contains both the value and the position in the display, so i don't exactly see how handlebars template could fit my needs. Or perhaps dynamically generating the template is an option ?
What do you think ?
Am I choosing the wrong framework or misunderstanding its use? is it my original MVC design that is wrong ? Changing the data model for something completely different is not an option i can easily consider as it would impact everything.
Do you have any ideas on how this could be implemented using Ember or some other framework?
Any advice will be appreciated :)
I made a rudimentary example on jsfiddle on how you could use ember for this.
Each row is an object and we have an ArrayProxy holding such objects. Thus if we have 10 rows, we have 10 row objects.
The view is binding one output line per row object.
Enjoy the flying bird:
http://jsfiddle.net/algesten/YMrW3/2/
Edit: Better to {{#if}} away empty rows as pointed out by ud3323:
http://jsfiddle.net/ud3323/92b24/

Partial View or HtmlHelper for displaying list of items

I have a model that contains an IEnumerable of a list of custom objects. Each item needs to be displayed with about 6 fields and an image. So, I won't be using a grid to display the items, rather a div and styling to achieve the look I want. With that said, I'm looking for the appropriate approach. In the book I have, Pro ASP.NET MVC 3 Framework by Adam Freeman and Steven Sanderson, they give an example of doing something similar in their Sports Store application, where for each item, they use this code,
#foreach(var p in Model.Products) {
Html.RenderPartial("ProductSummary", p);
}
Most other reading that I've done, and what seems to be a preferred approach to this, would be to use an HtmlHelper that does basically the same thing.
Which is preferred and why would I use one approach over the other?
Thanks
EDIT
I should have mentions that each of my items will be enclosed in it's own form and have a submit button. This may be the reason the authors of the book I mentioned used the partial view.
In my opinion, I would go the helper route if there is a chance that the code would be reused somewhere else. Could it be used on another page? Or in another project?
Something else to think about...
Helpers also help you to encapsulate view code so that you can keep your view clean and simple. How complex is that view? Would encapsulating some of the code assist in making the code easier to read and maintain?

Resources