While cforms is excellent for developing form based applications, it has some (minor) problems if Cocoon is used in a portal environment, being it the Cocoon portal or Cocoon used as a JSR 168 portlet in a different portal container. One of the problems is the uniqueness of ids in the resulting html: each form and input field gets an id based on it's definition in the model. While this works perfectly in a standalone environment this might lead to problems with portals: the portlet may be displayed more than once or the generated ids might interfere with ids generated by other portlets. Therefore a portal usually provides kind of a namespace for each portlet. Fortunately, CForms based applications can make use of such namespaces if you set the id of the form to this namespace. This will then lead to unique ids as the id of the form is prefixed to each input field (the mechanism is in fact more general). The only drawback is that you have to specify this id in the model. And this means that the model is dynamic as each portlet instance must have an own model as each instance must have a different id for the form. This works but of course the form model is never cached.
To make cforms more portal friendly I suggest to extend the form creating a little bit by: - adding a createInstance(String formId) method to the FormDefinition - adding createForm(source, String formId) methods to the FormManager - adding a Form(formDefinition, formId) method to form.js WDYT? Or is there a better solution? Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
