views:

51

answers:

1

Hello - I'm porting an existing system to ASP.NET MVC2. In the current legacy app, the user can select from dozens of available fields to customize CRUD forms for different entities in the domain model, similar to the way ERP systems allow customization of core modules.

My question: I'm looking for a good pattern or example for this kind of behavior in ASP.NET MVC2. It seems to me it's rather like creating a ViewModel dynamically based upon user choices, or perhaps the right approach is data-driven view pages that aren't strongly-typed where I can reflect over the results client-side to determine field headings or something -- if that makes sense :). Or maybe I can drive AutoMapper or similar dynamically @ runtime based on user choices?

The underlying domain model is EF4-based and I'm using a simple Repository pattern @ present for the ViewModel.

TIA for any input! Michael

+1  A: 

If I didn't find anything else that matched the needs and went on to do it custom, I would:

  • Use the ViewModel with all the fields / not just the ones the user picked.
  • Pass both the ViewModel and the view configuration to the view
  • Call some html helper that for each item in the configuration adds a field with the corresponding property in the model
  • The configuration could be passed as either part of a containing ViewModel or in a separate entry in ViewData
  • Depending on what you need, building/passing the view configuration could be put in an Action Filter. Alternatively the helper could pull it directly.

A different approach is if you need completely custom fields. I mean user defined fields. If that's the scenario, that's not typed at the controller level already, so I'd pass the list of fields/values to the view. The view can do a foreach on those adding the fields. Again that could be moved to a HtmlHelper.

eglasius
Thanks Eglasius. I think your approach could work. Right now all fields a user can present are predefined -- they can change the labels to match their terminology, this is also like an ERP system. But I was hoping to avoid sending lots of data to the CRUD views unecessarily -- there are LOTS of optional fields. For "design time" sending all fields sounds like the right thing to do though, probably in a manner as you describe.
mcmSEA
+1 Just what I was thinking, I feel that the view configuration should be a distinct element of the view data. The main reason being is that if users can customise end CRUD form, these choices will need to be stored and in all likelihood there will be some further logic involved in maintaining the configuration.
Ahmad
Hi Ahmad - Yes we'd need to store each user's view configuration regardless. But if I take this route and send all fields all the time, it's not really dynamic or 'ad hoc', it's just controlling visibility based on configuration, right?
mcmSEA
@mcmSEA yes, it'd be controlling visibility. If its completely custom, I don't think building a model for it adds any value, I'd use lists of fields vs. values for it. In fact, I built a product that does it that way back in asp.net 1.0 / I don't think the forces involved for the particular challenge are any different.
eglasius