Sylvain Wallez schrieb: > 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)? > Yes, that was my first thought as well - but I was wondering if it's a good idea to "always" allow to change the id. So I thought that if the id is dynamic, it should be part of the constructor - therefore the above changes.
But of course just adding setId() works fine as well. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
