Reputation: 84325
I need to develop a generic jQuery-based search plugin for the ASP.NET MVC application I'm building, but I can't figure out how it's supposed to fit, or what the best practice is. I want to do the following:
$().ready(function() {
$('#searchHolder').customSearch('MyApp.Models.User');
});
As long as I have implemented a specific interface on Models.User, jQuery will be able to talk to a reflection service to generically construct the relevant UI.
Sounds fun, but it seems that I'm now calling the JavaScript from the View, which is in turn going to do some View-related activity to build the search UI, and then to do the search and interact with the user it's going to throw a bunch of Controller tasks in there.
So where does this really fit? Is there a different way I can structure my jQuery plugin so that it conforms more to the idea of MVC? Does MVC work when it scales down to its own form within another MVC structure? Should I just ignore these issues for the sake of one plugin?
Upvotes: 5
Views: 2218
Reputation: 11
so I have actually been looking into this a lot lot, and have found that the new officially supported jquery plugin tmpl can work as a view engine. I have written a tutorial here, how you can create a full MVC/MVP paradigm in JavaScript
Upvotes: 1
Reputation: 30160
It sounds to me like what you want are partials
, a RoR term so not sure that they exist in the same format in ASP.NET MVC. Basically a partial is a part of a View thats defined in its own file and can be called from anywhere. So in your search controller, you would pull out the Model asked for, do some reflection to get the data and construct it into JSON, and also grab the partial View for that model. You might find it easier if you follow a convention for naming the partials based on the Model name, to save you having any big switch
statements or extra config files.
I could be wrong, but it sounds like you're a bit worried making a call to the Controller from Javascript and getting HTML returned. Thats perfectly OK, its just a case of fetching the View appropriately and making sure you don't process the rest of the page, only what you need for that call (why MVC is so much better than UpdatePanel
s!)
Upvotes: 1
Reputation: 78852
Approach it as if you have two seperate systems, with models,views and controllers on the server and (Javascript/DOM) models, views and controllers on the client(browser). Ajax is just the client's method of requesting services from the Server.
Upvotes: 0
Reputation: 84325
Just to follow up (I'm very surprised nobody else has had any opinions on this), in an effort to keep best practice I've opted to adopt jTemplates.
It enables me to request some Model-style JSON from my server-side Controller and process it using syntax similar to that I would already use in a View, which now keeps any required JavaScript UI MVC-compatible. There's a small overhead in that the client will need to request the View template from the server, but if that becomes too slow I can always sacrifice a little and send it over with the initial JSON request.
Upvotes: 2
Reputation: 11358
I'm not sure I understand what you're trying to accomplish, but I would construct the relevant UI on the server as part of your view (e.g. as a user control that can be rendered on different pages), set it's display:none style and use JQuery on the client side to show it when the user clicks on some link or whatever.
After that the plugin would use $.ajax to send the search request to your application where you can perform relevant activities and render a partial view with your search result. Your ajax code would then pick it up and insert it in your document.
Upvotes: 0