I have a User model with some validations behind it.
What I'd like to do is have a signup form on every page of the app, even the mostly static ones.
I figured the best way to do this would be through helper methods in application_helpers.rb, which works fine, but validations don't seem to work.
I can also serve the form through an iframe, but that seems a bit hacky.
I'm using partials now, but my client side validation (github.com/bcardarella/client_side_validations) only works on the /new page, not the application page.
What's the best practice in this case?
I would recommend extracting the signup form into a shared partial, which you then explicitly could render wherever you want it.
One could render the signup form directly in the layout file (app/views/layout/application.html.erb) if the placement is static no matter of what page you're currently on.
One of the basic solutions is to use partial. The benefit is: it's built in, it's simple. The downside is: You'll be busy to feed it some session details for proper rendering.
Another solution is to use Cells for this kind of case.
Cells works like a lightweight controller which can do anything a controller can do, and it's independent on any controller. One good use case of Cells is shopping cart, and login form is also a good use case in my opinion.
Related
I'm very much a web forms man and am coming over to mvc using mvc 4.
Am I missing something or is the norm with a thank you or response page to create a separate view and direct off to that.
So for instance if a user fills in a contact us form, clicks submit, the user then needs to see a thank you message on the page.
This would be done using the same web form but am i right in thinking i should create a new view?
If this is the case doesn't a site soon fill up with a LOT of very simple views?
If you are referring to PRG pattern, then the answer is yes, preferred way is to redirect user to the separate action which will in turn return a "Thank you" view.
However, nothing stops you from creating such an action that will for example bind to your specific model and according to that decide in your view what to render.
That way, you shouldn't and up with many "Thank you" views.
EDIT:
ASP.NET MVC technology itself is a set of best practices and conventions. There is nothing to stop you to use it the 'wrong' way.
But what exactly would be wrong way here?
using a lot of small views could reduce the mess and give you some flexibility; imagine the situation where suddenly you have to change each of "Thank you" views in the way to tell the user something about the action completed and to point him toward the next one
using some view-related logic in template can in extreme cases reduce all of those "Thank you" views to few or just one; in the other hand you could end up with a big and ugly Razor template
using partial view could help you with the first problem, but then you have to be careful where you put your partals - you want to reduce mess, not generate more
using helpers in views could be helpful to encapsulate a small parts of the view that repeats throughout multiple views
So I have a highly customized CMS type system where users can manage content on pages. For the most part everything is templatized, however, the home page is unique in so much that it has additional, editable content that a regular page does not have.
The two solutions that I thought of for this are:
1) I could add a new model, controller, and table in the DB making this an entirely new component. However that seems like a lot of trouble to go through for one page.
2) I could add the missing columns for the home page to the general "pages" table, but again that seems sub-optimal as the additional columns would only ever be used for home page.
What's the best way of handling a situation like this? Is there an additional way that I haven't thought of?
IMHO it really depends on the site and how much differs b/n the homepage and other pages as well as what DB-interaction the homepage has. Kind of a tough question to answer generally.
One thing I've done in the past that has worked well is to have a "Home" record in the CMS tool (assuming there's a 'content' field you can access). Then build that custom controller/view for the homepage -- it is the homepage after all.
Add in your custom functionality, custom layout, formatting, etc. And pull that 'content' field from the 'Home' record in the CMS and insert it where relevant.
That way, the CMS staff can still tweak the homepage messaging, but you maintain full db-interactivity over it.
Hope that makes sense.
I wouldn't advise against #2. Seems wasteful.
I ended up just creating a Model, Controller, table, etc. for generic 1-off pages that are flexible as I suspect that I'll have need for additional stand alone pages in the future. The home page is just one of those now with a special route a method in the controller.
I am currently considering the best way of building a relatively complex page in asp.net mvc. The page (and pages like it) will contain numerous 'controls' such as a shopping basket, recent news widget, login controls and more. In other words, it will be very component based.
My question is, what is the best way of building something like this in asp.net MVC? In regular webforms the answer would be simple thanks to user controls and the fact they can be nicely self contained. In MVC, I understand that in theory I should probably build a viewmodel that includes all the data needed for all my widgets and then render partial views in whatever page I'm building.
Could an alternative approach be to use javascript to load widgets 'dynamically' (think jQuery load) by simply calling into controllers that render partial views. That way I could have a basket controller, which when called renders out a basket. Of course, this relies on javascript....
Whats the best practise for situations like this?
Thanks
You could of course use JavaScript to populate the page sections but then this content will not be accessible to search engines (but that probably does not concern you).
What you need to understand that there is currently no way to make these partial views perform independently. Like talking to their own controller and posting data while having the rest of the stay unchanged (like it could have been done with WebForms and user controls). If you think postbacks and control state these things do not exist any longer. Your "control" makes a post, the controller has to process the request and then recreate the complete view along with all element values, states and other "user controls".
Unless you do it asynchronously with JavaScript of course. But then it's not gonna be an accessible page any more.
You can try SubControllers from MvcContrib or Steve Sanderson`s "Partial Request" approach.
But i warn you - communication between (partial requests, i haven't tried subcontrollers myself) them might get tricky and lead to mega failure. Use them only if you are completely sure that they are completely independent.
Anyway - that's a bad idea and should be avoided through controller/viewmodel inheritance or something....
My understanding of MVC is not yet up with WebForms, however is the generally accepted approach for stuff like this to simply throw these things in the ViewBag rather than include them in the ViewModel?
You could send down a main view model with some simple checks on it. Then render the appropriate Action if required. Then each partial could use it's own viewmodel and you wouldn't need to send everything down initially on the same viewmodel.
Razor:
#if (model.ShowShoppingCart)
{
#Html.Action("Index","ShoppingCart")
}
#if (model.blah)
{
#Html.Action("Index","blah")
}
I'm looking for a best practice suggestion.
I've got a ShoppingBag Controller with a Partial that lists all the items in the user's bag. In this Partial you can remove items from the bag via a form post.
The Partial has been place in a Master Page which is referenced by each of the Views in the Controller. When an item is removed from the user's bag, I'd like the user to be redirected to the originating View. I'm quite happy with how I would achieve this with JavaScript, it is the non JavaScript I am not clear about.
Do I:
Detect the referring Action using Request.UrlReferrer and redirect. This could be quite laborious detecting the Action/Route from a URL.
Pass a hidden field with the Post. Not really keen on the thought of bloating the HTML.
Don't redirect to originator, redirect to a confirmation page. Would prefer to avoid if possible.
Something I've missed.
Any helped would be appreciated.
Rich
Definitely #2. It's not bloat, it's expressing your intent. It'll be 50 bytes, don't sweat it, you should be gzip'ing your HTTP anyway.
However, do make sure that you secure it such that someone can't put any old page in there, or another site. Perhaps use an enum value if the number of originating views is constrained.
I'm looking to build a rails web app with an admin control panel. I'd like the control panel to use a tabbed interface for controlling users, projects, tasks etc, and I'd like to switch between tabs using jquery tab UI controls with ajax. Also using restful authentication for users and my own code for projects, tasks etc.
Here's what I can't wrap my head around. Normally, I'd have a controller for each tab, so validation is simple, if there's an error (say in the user) i just render the proper action with the object and it's errors and we're set. However, if I'm not refreshing (to different controllers between tabs) how does this work? Do I need to have one massive controller with all the user, project, task validation and controls (ie. crud operations)? Seems like not the greatest design.
Or is there some way I can use an 'admin' controller that encompasses separate controllers for proper crud/error checking etc.
Hope this makes sense?
I would make the contents of each tab be called in by a separate ajax request. This would give you the following benefits
Now each tab can easily be a different view/controller
You only need to load the contents for a tab when it is used; you won't be processing code/downloading html for tabs that the user doesn't use.
If you don't want to use this route, (i.e. you feel you need to load all the contents of the tabs on page download in a single request) then you could separate out the code using helper methods and partials. See my answer here: Rails Sub-controllers?
I would personally use inline validation in the forms. Jquery does that pretty well , but there are a lot of library that can help you with that.
I guess it's not exactly what you were looking for, but it would make your job easier. Of course still keep validation in the models so that no one can bypass the validation (using firebug or something like this)