Move forms from resources plan

Development Steps

1. Create a helper within metaobj package that will take the xsd and use xslt to render an "add" form
2. Create an xslt to render an "edit" form
3. Replace calls in the OSP tools to the resources form helper with calls to the new metaobj forms helper
4. Work with Jim to get a pluggable helper interface into the resources tool (this may already be in place for the citation work)
5. Turn off the current resources forms support

As you can see, this step by step approach will have the least amount of impact on the 2.4 trunk development. Up until step 3, there will be no noticable change. Up until step 5, the current forms support will still be in place. The goal will be to keep the forms stored in ContentHosting in the same way they are now. That way, between steps 3 and 5, people will still be able to edit/create forms either in the new metaobj helper or in the resources tool. This goal will also make migration much easier.

Step 4 should really be done in parallel with the other steps in the process.

After these things are complete, some more forms enhancements to consider would be (in no particular order)

• Add ability to specify a different xslt for rendering a form than the default xslt. This feature would greatly enhance the customizability of forms allowing for almost endless rendering possibilities.
• Create a set of xslt templates that handle certain field types for use in custom xslt form renderers.
• Add ability to pull fields from other forms. For instance, if there is a complicated field (such as a phone number field) user's can refence the field in an xsd they create.
• Add a UI for creating the xsd definition of a form
• Add a UI for creating a customize xslt for rendering a form
• Add some new field types ???