You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@apache.org> on 2006/03/26 11:47:51 UTC
CForms and Portlets - making form ids dynamic
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?
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: CForms and Portlets - making form ids dynamic
Posted by Sylvain Wallez <sy...@apache.org>.
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 equally well standalone or within the portal, you
> say. You have never developed CForms in portal, have you?
>
Nope, and you know it well :-)
Now what I'm saying is that a form *should* run equally well standalone
or in the portal!
Sylvain
--
Sylvain Wallez
http://bluxte.net
Apache Software Foundation Member
Re: CForms and Portlets - making form ids dynamic
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
* 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 portal, you
say. You have never developed CForms in portal, have you?
--
Jean-Baptiste Quenot
http://caraldi.com/jbq/
Re: CForms and Portlets - making form ids dynamic
Posted by Philippe Gassmann <ph...@anyware-tech.com>.
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 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).
>
>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?
>
>
>
Yes, it is possible to test if an entry "cocoon-portal-copletId" is in
the objectModel.
>Sylvain
>
>
>
--
Philippe GASSMANN
Solutions & Technologies
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com/
Re: CForms and Portlets - making form ids dynamic
Posted by Carsten Ziegeler <cz...@apache.org>.
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/
Re: CForms and Portlets - making form ids dynamic
Posted by Sylvain Wallez <sy...@apache.org>.
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).
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?
Sylvain
--
Sylvain Wallez
http://bluxte.net
Apache Software Foundation Member
Re: CForms and Portlets - making form ids dynamic
Posted by Carsten Ziegeler <cz...@apache.org>.
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/
Re: CForms and Portlets - making form ids dynamic
Posted by Sylvain Wallez <sy...@apache.org>.
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)?
Sylvain
--
Sylvain Wallez
http://bluxte.net
Apache Software Foundation Member
Re: CForms and Portlets - making form ids dynamic
Posted by Carsten Ziegeler <cz...@apache.org>.
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 do things like redirects etc. In the end the developer of the
>> forms does not have to know about the portal environment - the only
>> thing is this id.
>>
>
> It would be interesting if you could share your experience, as
> integrating CForms with the portal seems to be a major pain for a lot of
> people.
>
Sure, see my reply to JBQ. We just use the usual url rewriting stuff
that is used for other apps as well - and that's it :)
> And let's go for Form.setId() as a first step for an easier integration.
>
Ok, I'll do the changes today or tomorrow, great!
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: CForms and Portlets - making form ids dynamic
Posted by Sylvain Wallez <sy...@apache.org>.
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 etc. In the end the developer of the
> forms does not have to know about the portal environment - the only
> thing is this id.
>
It would be interesting if you could share your experience, as
integrating CForms with the portal seems to be a major pain for a lot of
people.
And let's go for Form.setId() as a first step for an easier integration.
Sylvain
--
Sylvain Wallez
http://bluxte.net
Apache Software Foundation Member
Re: CForms and Portlets - making form ids dynamic
Posted by Carsten Ziegeler <cz...@apache.org>.
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 about the portal
>> environment - the only thing is this id.
>
> If you are not using continuations or you are only using one form
> in the page, of course there is no problem.
>
We are using continuations.
> When issuing a redirect, it works, you're right, but there's an
> error in the logs.
>
> And yes, the developer needs to know about the portal because of
> <form action="portal">. You would never do that in a standalone
> app.
>
No, you don't have to do that. The portal rewrites all urls of the form
application like it does with the google sample. You can use the same
technique for cocoon based apps as well. For example the calculator
example in the demo portal is included in that way as well.
So, the cforms can use whatever he wants and does not have to care about
the portal environment; with AJAX the picture might change, I haven't
looked into that but will in the next weeks.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: CForms and Portlets - making form ids dynamic
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
* 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 - the only thing is this id.
If you are not using continuations or you are only using one form
in the page, of course there is no problem.
When issuing a redirect, it works, you're right, but there's an
error in the logs.
And yes, the developer needs to know about the portal because of
<form action="portal">. You would never do that in a standalone
app.
Best regards,
--
Jean-Baptiste Quenot
http://caraldi.com/jbq/
Re: CForms and Portlets - making form ids dynamic
Posted by Carsten Ziegeler <cz...@apache.org>.
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 container.
>
> I would say that developing CForms together with Portal does not
> exhibit *minor* problems, I would rather say it's a major PITA!
>
> Why? Because most users develop CForms together with FlowScript's
> continuations. And this exposes several problems:
>
> 1) if you have several forms on your page, when you post a form,
> all forms believe they are being continued leading to an
> exception being thrown
>
> 2) if you post directly to your FlowScript's pipeline, there's no
> way to display the portal
>
> 3) the FlowScript is not the controller, leading to awkward
> situations like not being able to issue a redirection (may be
> a general issue with portals)
>
> It's possible to circumvent problem 1) by using CachingURICoplets
> and by invalidating the cache of the target coplet upon form
> submission.
>
> WDYT? IMO your current work is very valuable because it would
> allow better integration between portal and forms. However, I'm a
> bit disappointed because badly mixing and hacking portal and
> CForms is the only way we had to go for years! I wish this random
> id feature was there since the beginning.
:) 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 etc. In the end the developer of the
forms does not have to know about the portal environment - the only
thing is this id.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: CForms and Portlets - making form ids dynamic
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
* 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 developing CForms together with Portal does not
exhibit *minor* problems, I would rather say it's a major PITA!
Why? Because most users develop CForms together with FlowScript's
continuations. And this exposes several problems:
1) if you have several forms on your page, when you post a form,
all forms believe they are being continued leading to an
exception being thrown
2) if you post directly to your FlowScript's pipeline, there's no
way to display the portal
3) the FlowScript is not the controller, leading to awkward
situations like not being able to issue a redirection (may be
a general issue with portals)
It's possible to circumvent problem 1) by using CachingURICoplets
and by invalidating the cache of the target coplet upon form
submission.
WDYT? IMO your current work is very valuable because it would
allow better integration between portal and forms. However, I'm a
bit disappointed because badly mixing and hacking portal and
CForms is the only way we had to go for years! I wish this random
id feature was there since the beginning.
--
Jean-Baptiste Quenot
http://caraldi.com/jbq/