Is XSL the right tool to deliver and process custom forms?

I am developing an ASP.NET MVC application on which I provide the end users with a particular form asking for pretty standard stuff, name, phone number, address, etc. However, some of the users will need to ask me for additional pieces of input, for which I have no way to plan. In addition, some of these forms may have slightly different processing logic. For example, if they prov开发者_JS百科ide two addresses, they only need to give me one phone number. Or, apply a different processing fee for a specific zip code. Again, I have no way to know what those customizations are going to be in the wild.

Now, I don't want to have to bake these forms and logic into my application, recompile and republish every time I get a request for custom work, that would get really messy and bloated very quickly. Bad plan.

I recently had a look XSL stylesheets, with which I have no experience, but I get the idea that using XSLT could solve my problem in full. Am I on the right path? Does anyone have any advice on how to dynamically deliver forms and process logic associated with those forms? Any good tutorials out there on XSL within ASP.NET MVC?

Thanks!

This seems like a reasonable way to solve the issue. What you may want to consider is using xsl/xml with PartialViews so that you can decide which PartialViews to render according to the rules out there in the wild.

So each PartialView would handle an atomic piece of data like an address or a phone. You can attach data to it describing where to store that info in your xml/xsl.

What it means for you is that you can have atomic pieces of functionality and the xsl file can describe what to render and where.

If you design this right, you will also be able to add fields to the PartialView dynamically and the code should be able to handle it no probs.

The design issue you might run into is once you have the data in the xml document, how do you save it? As an xml doc in the database or will you pull the pieces of data out into tables and fields. The latter is obviously the prefered choice. So come up with a strategy that will allow you to easily pull data out and store in the table.

A lookup table might be the way or you may store table and field info inside the xml document.

All this sounds complex I know but really isn't once you have your initial xml document designed.

This is the way I did it: I have a From Processor page that takes every field submitted in the form POST, and saves them to the DB as children of a form post object. Then I use an NVelocity template to display the form data. This way, all you have to do is make new standard HTML forms, and have their actions point to your form processor page, and make new NVelocity templates to display the new forms.

If you choose this route and need more help implementing it, post a comment, and I'll give you more info.

Thanks to Josh Pearce and greigs both. Although neither of your ideas was exactly what I needed, each of them had merit and gave me inspiration for arriving at a solution that I think will work.

Each of my clients will have a group of preferences that I will be able to control. One of those preferences can be "Use custom Blah form [t/f]". If I set that to true, I can have my controller try to find a View by the name of "ClientIdentifier_BlahForm". If it isn't found, I will just present the default view for that form.

The business rules for this form should be simple enough to handle in JavaScript. Additionally I can have some measure of standardization in my controller. For example, any form value that I get with "PhoneNumber" in its name gets validated as such, etc. From there, I can simply package up my name/value pairs and send them along to their final destination.

Thanks again.