cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: CForms and Portlets - making form ids dynamic
Date Mon, 27 Mar 2006 07:52:51 GMT
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 Ziegeler - Open Source Group, S&N AG

View raw message