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 08:37:06 GMT
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
>> Sylvain Wallez schrieb:
>>> 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.
> It seems to me that the form writer should not have to care about
> setting a dynamic ID on the form, as it's more an integration concern (a
> form could run equally well standalone or within the portal).
That would be ideal, but this is never the case in practice. And this is
neither a problem of Cocoon or the Cocoon portal. Regardless of what
framework or portal you're using, there are always problems and in the
end a developer has to know.

> Is there a simple test that can be performed (without introducing a
> dependency on the portal block) that can allow us to detect that we're
> running as a coplet and then set a dynamic ID on the form?
Hmm, this sounds like too much magic for me, but it's doable. The
problem here is that every portal might do this in a different way. If
we are speaking about the cocoon portal, that's easy because we can
provide any information required. But if we are running as a JSR 168
portlet in any container it's harder.
So, I think we should just add the setId() method for now.
In fact, Cocoon does not integrate well into the JSR 168 world anyway as
we do not separate between the action and the rendering phase.

Carsten Ziegeler - Open Source Group, S&N AG

View raw message