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 -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
