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
* Carsten Ziegeler:
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.
I would say that
* Sylvain Wallez:
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).
A form could run equally well standalone or within the
Jean-Baptiste Quenot wrote:
* Sylvain Wallez:
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).
A form could run
Sylvain Wallez a écrit :
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
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
Jean-Baptiste Quenot schrieb:
* Carsten Ziegeler:
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
Carsten Ziegeler wrote:
:) All I'm asking for right now is to have a dynamic id on the form.
Nothing more and nothing less.
We are using cforms and the portal in several projects without the
problems. We are using the CachingURICoplet and some other components
and can do things like redirects
* Carsten Ziegeler:
We are using cforms and the portal in several projects without
the problems. We are using the CachingURICoplet and some other
components and can do things like redirects etc. In the end the
developer of the forms does not have to know about the portal
environment
Jean-Baptiste Quenot wrote:
* Carsten Ziegeler:
We are using cforms and the portal in several projects without
the problems. We are using the CachingURICoplet and some other
components and can do things like redirects etc. In the end the
developer of the forms does not have to know
Sylvain Wallez schrieb:
Carsten Ziegeler wrote:
:) All I'm asking for right now is to have a dynamic id on the form.
Nothing more and nothing less.
We are using cforms and the portal in several projects without the
problems. We are using the CachingURICoplet and some other components
and can
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
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
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
14 matches
Mail list logo
