Carsten Ziegeler wrote: > 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? >
What about simply adding Form.setId(String formId)? Sylvain -- Sylvain Wallez http://bluxte.net Apache Software Foundation Member
