views:

1297

answers:

4

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?

A: 

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.

liggett78
I'm creating a bespoke search interface via reflection for each type, so I can't pre-define the HTML. Thus, I'm almost needing to structure a mini-MVC within the plugin, but I can't work out if it's worth it!
tags2k
Why don't you create a different interface on the server-side in the user-control depending on your type? I would find it at least much easier than trying to stick together DIVs and INPUTs in javascript.
liggett78
I'd like to be able to instantiate the search interface anywhere in the site for any type, without having to pre-define what it's going to look like. Need to look for orders? $('#div').customSearch('Orders'), job done!
tags2k
But somewhere you need to define how your UI for searching orders is gonna look like, be it in your javascript or on the server-side.You can send another ajax request upon page load or when user clicks on search link to get the UI, depending on whether it's order, customer or whatever.
liggett78
That's exactly my question - where is it best practice to define the UI? Traditionally, the View would be the correct place but this isn't possible if your UI is built generically, and if you might have a User search in many pages, it doesn't make sense to copy and paste the markup every time.
tags2k
I'd say that you should be making a request to the controller and the controller should figure out what view or parts of the view to render and passing that info to the view via a model
Corin
+2  A: 

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.

tags2k
A: 

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.

Ken
+1  A: 

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 UpdatePanels!)

roryf