Novice on this 'asp.net mvc' but familiar with mvp pattern for mobile app(mvc#).
Required business logic is to display 'firmware version' in a format like "1.03".
I found it can be formatted either in Controller:
ViewBag.deviceFirmwareVersion = String.Format("{0}.{1}", result.VERSION_MAJOR[0], result.VERSION_MINOR[0]);
or in View:
<td>#String.Format("{0}.{1}", Model.VERSION_MAJOR[0], Model.VERSION_MINOR[0])</td>
Then, what is the difference? Of course I preferred doing it in a Controller. Mvc# makes view as simple as possible (dumm view) and let it depends on presenter about what to do. Is there a simliar rule here?
[02 Nov 12] Maybe my question was a bit off focused, I ended up creating view model where I pick up necessary pieces from data entity and formatting them for view. This link helped me.
With MVC paradigm, all the things about showing informations has to be described in the View, because informations can be get in differents formats (HTML, JSON, XML) and if you format the data in controller then you have to check for every type of format you may show.
If you use only HTML can be easy now to set data format in the controller, but further can get you in trouble.
(Sorry for bad English)
Related
I have written python code that analyses two text sources and compares them.
I'd like to implement this dynamically via two text boxes that a user could either type into or manually upload. I have already begun coding this using HTML. Would it be better to implement a widget or the models instead to make the text area boxes?
Edit:
I wrote this question when I was just figuring Django out, so forgive me if it sounds confusing. But everyone starts somewhere. I'm unable to delete the question as contributions have been made already. YouTube courses proved helpful in learning the basics, if any beginners stumble upon this.
You use a form object. Django has form objects (https://docs.djangoproject.com/en/2.0/topics/forms) that take a model and translate it into html elements. So I guess in a way, you implement the model but I want to stress that that's not actually what's happening from a technical standpoint. A better way to say it is that you're implementing forms. The reason I stress this so much is so that you understand what's really going on so that you don't have misunderstandings that end up costing you in code clarity and readability.
So to answer your question, you can implement django forms to do this very easily. The way you implement it depends on your models and how they are designed since the forms use the models to create the right html form elements. If you're dealing with one model that will be instantiated by the form input, create a model form. This will take the input from the form and create your model instance. If you're dealing with one form that uses multiple models, then use a generic form. In this case, you will have to write your own save method that does the actual logic of the form.
One other thing to add... No matter what, your end result will always be a widget on the HTML in the end. Django forms translate a model class into a form element with input elements. If you didn't use Django forms, you would still do the translating, but you would have to do it from scratch.
I hope this helps and that I correctly understood your question.
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.
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 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?
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.