You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Ralph Rauscher <rr...@blue-elephant-systems.com> on 2009/01/20 23:42:44 UTC

CForms Serialization

Hi,

I have a case where I have a really large form that would require 
several sessions to be valid and I'd like to allow users to persist 
their work (even if the form is invalid) and continue working on it later.

As the cforms binding will throw all kinds of exceptions in this case I 
thought about serializing the Form object using standard Java object 
serialization.

So far Form and the classes it's derived from do not implement 
Serializable, which would be easy to fix. I saw a remark though by 
Sylvain where he mentions

/"a form contains its own data model, which can be serialized, but also 
pointers to its definition, which is shared between form instances and 
can contain arbitrary references to non-serializable objects and components"

/So, is it possible?

Thanks.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

AW: AW: CForms Serialization

Posted by Christofer Dutz <ma...@c-ware.de>.
Hi Ralph,

ok ... you're right with this one ... but on the other side. Why should you
enter a non-number in an integer field anyway?
But, as you mention it. I really hated the guys entering "half a dozen" in
one of my applications "amount" fields, complaining about it not working.
;-)

Still, I think it is a very small "but". 

Wouldn’t it be possible to define your field as a string field and add some
kind of "IntegerValidator", checking if the String is Integer?
Maybe you could define two types of binding. One with plain string and one
doing an Integer cast (Don't know if there are converters for this or you
have to do some custom binding).


But to continue the discussion about separating form definition and
(internal)-form model. Separating it, would result in the need to do
something like this:

formModelObject.load(applicationModelObject);
formDefinitionObject.showForm(fromModelObject);
formModelObject.save(applicationModelObject);

Otherwise I doubt it would work. And having a formModelObject and an
applicationModelObject sort of sounds silly ... what would be great thou,
would be being able to work directly on the applicationModelObject. But I
guess this would be a little tricky as even the
fromModel-to-applicationModel-mapping starts getting tricky as soon as you
start having more complex object structures.

Chris




-----Ursprüngliche Nachricht-----
Von: Ralph Rauscher [mailto:rra@blue-elephant-systems.com] 
Gesendet: Mittwoch, 21. Januar 2009 20:36
An: users@cocoon.apache.org
Betreff: Re: AW: CForms Serialization

Hi Chris,

seems that would do the trick for fields where I have validators defined 
in the model. I've found though it will not work eg. for fields that I 
have defined as being of type integer. In that case, the binding calls 
the getValue() method for the integer widget which automatically tries 
to validate it and returns null if that value is not an integer - so the 
output of the binding for that widget will be empty....

Thanks.

Christofer Dutz wrote:
> Hi Ralph,
>
> it should be possible, if you extract the data from the form and persist
> that.
>
> I think you could add a parameter to a submit-widget to not validate the
> form (this would be the easiest way), this way you can return to your
> flowscript or javaflow and continue processing. Alternatively you could
add
> a link on your form for example "save form" that passes the current
> continuation-id as a parameter to a save-url (Be sure to have the most
> recent continuation id in Ajax enabled forms). In the logic for processing
> this url, you could use the continuation-id, to get the form instance and
> continue-from there (to see how this is done ... have a look at the
> suggestion-list generator.
>
> If you use form.save(previouslySavedFormData) to save your forms content
to
> a java-pojo or w3c.dom there should be no problems in persisting them ...
as
> soon as the user wants to continue: form.load(previouslySavedFormData);
and
> you should be ready to continue.
>
> Hope this helps,
>     Chris
>
>
>
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Ralph Rauscher [mailto:rra@blue-elephant-systems.com] 
> Gesendet: Dienstag, 20. Januar 2009 23:43
> An: users@cocoon.apache.org
> Betreff: CForms Serialization
>
> Hi,
>
> I have a case where I have a really large form that would require 
> several sessions to be valid and I'd like to allow users to persist 
> their work (even if the form is invalid) and continue working on it later.
>
> As the cforms binding will throw all kinds of exceptions in this case I 
> thought about serializing the Form object using standard Java object 
> serialization.
>
> So far Form and the classes it's derived from do not implement 
> Serializable, which would be easy to fix. I saw a remark though by 
> Sylvain where he mentions
>
> /"a form contains its own data model, which can be serialized, but also 
> pointers to its definition, which is shared between form instances and 
> can contain arbitrary references to non-serializable objects and
components"
>
> /So, is it possible?
>
> Thanks.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
>   


-- 
Ralph Rauscher

 blue elephant systems GmbH
 Wollgrasweg 49
 D-70599 Stuttgart

 Tel   :    (+49) 0711 - 451017 574
 Fax   :    (+49) 0711 - 451017 573
 e-mail:    rra@blue-elephant-systems.com
 Sitz  :    Stuttgart, Amtsgericht Stuttgart, HRB 24106
 Geschäftsführer: Joachim Hörnle, Thomas Gentsch, Holger Dietrich  


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

Re: AW: CForms Serialization

Posted by Ralph Rauscher <rr...@blue-elephant-systems.com>.
Hi Chris,

seems that would do the trick for fields where I have validators defined 
in the model. I've found though it will not work eg. for fields that I 
have defined as being of type integer. In that case, the binding calls 
the getValue() method for the integer widget which automatically tries 
to validate it and returns null if that value is not an integer - so the 
output of the binding for that widget will be empty....

Thanks.

Christofer Dutz wrote:
> Hi Ralph,
>
> it should be possible, if you extract the data from the form and persist
> that.
>
> I think you could add a parameter to a submit-widget to not validate the
> form (this would be the easiest way), this way you can return to your
> flowscript or javaflow and continue processing. Alternatively you could add
> a link on your form for example "save form" that passes the current
> continuation-id as a parameter to a save-url (Be sure to have the most
> recent continuation id in Ajax enabled forms). In the logic for processing
> this url, you could use the continuation-id, to get the form instance and
> continue-from there (to see how this is done ... have a look at the
> suggestion-list generator.
>
> If you use form.save(previouslySavedFormData) to save your forms content to
> a java-pojo or w3c.dom there should be no problems in persisting them ... as
> soon as the user wants to continue: form.load(previouslySavedFormData); and
> you should be ready to continue.
>
> Hope this helps,
>     Chris
>
>
>
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Ralph Rauscher [mailto:rra@blue-elephant-systems.com] 
> Gesendet: Dienstag, 20. Januar 2009 23:43
> An: users@cocoon.apache.org
> Betreff: CForms Serialization
>
> Hi,
>
> I have a case where I have a really large form that would require 
> several sessions to be valid and I'd like to allow users to persist 
> their work (even if the form is invalid) and continue working on it later.
>
> As the cforms binding will throw all kinds of exceptions in this case I 
> thought about serializing the Form object using standard Java object 
> serialization.
>
> So far Form and the classes it's derived from do not implement 
> Serializable, which would be easy to fix. I saw a remark though by 
> Sylvain where he mentions
>
> /"a form contains its own data model, which can be serialized, but also 
> pointers to its definition, which is shared between form instances and 
> can contain arbitrary references to non-serializable objects and components"
>
> /So, is it possible?
>
> Thanks.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
>   


-- 
Ralph Rauscher

 blue elephant systems GmbH
 Wollgrasweg 49
 D-70599 Stuttgart

 Tel   :    (+49) 0711 - 451017 574
 Fax   :    (+49) 0711 - 451017 573
 e-mail:    rra@blue-elephant-systems.com
 Sitz  :    Stuttgart, Amtsgericht Stuttgart, HRB 24106
 Geschäftsführer: Joachim Hörnle, Thomas Gentsch, Holger Dietrich  


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

AW: CForms Serialization

Posted by Christofer Dutz <ma...@c-ware.de>.
Hi Ralph,

it should be possible, if you extract the data from the form and persist
that.

I think you could add a parameter to a submit-widget to not validate the
form (this would be the easiest way), this way you can return to your
flowscript or javaflow and continue processing. Alternatively you could add
a link on your form for example "save form" that passes the current
continuation-id as a parameter to a save-url (Be sure to have the most
recent continuation id in Ajax enabled forms). In the logic for processing
this url, you could use the continuation-id, to get the form instance and
continue-from there (to see how this is done ... have a look at the
suggestion-list generator.

If you use form.save(previouslySavedFormData) to save your forms content to
a java-pojo or w3c.dom there should be no problems in persisting them ... as
soon as the user wants to continue: form.load(previouslySavedFormData); and
you should be ready to continue.

Hope this helps,
    Chris






-----Ursprüngliche Nachricht-----
Von: Ralph Rauscher [mailto:rra@blue-elephant-systems.com] 
Gesendet: Dienstag, 20. Januar 2009 23:43
An: users@cocoon.apache.org
Betreff: CForms Serialization

Hi,

I have a case where I have a really large form that would require 
several sessions to be valid and I'd like to allow users to persist 
their work (even if the form is invalid) and continue working on it later.

As the cforms binding will throw all kinds of exceptions in this case I 
thought about serializing the Form object using standard Java object 
serialization.

So far Form and the classes it's derived from do not implement 
Serializable, which would be easy to fix. I saw a remark though by 
Sylvain where he mentions

/"a form contains its own data model, which can be serialized, but also 
pointers to its definition, which is shared between form instances and 
can contain arbitrary references to non-serializable objects and components"

/So, is it possible?

Thanks.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

Re: CForms Serialization

Posted by Ralph Rauscher <rr...@blue-elephant-systems.com>.
Rice Yeh wrote:
>
>
> On Wed, Jan 21, 2009 at 6:42 AM, Ralph Rauscher 
> <rra@blue-elephant-systems.com <ma...@blue-elephant-systems.com>> 
> wrote:
>
>     Hi,
>
>     I have a case where I have a really large form that would require
>     several sessions to be valid and I'd like to allow users to
>     persist their work (even if the form is invalid) and continue
>     working on it later.
>
>     As the cforms binding will throw all kinds of exceptions in this
>     case I thought about serializing the Form object using standard
>     Java object serialization.
>
>     So far Form and the classes it's derived from do not implement
>     Serializable, which would be easy to fix. I saw a remark though by
>     Sylvain where he mentions
>
>     /"a form contains its own data model, which can be serialized, but
>     also pointers to its definition, which is shared between form
>     instances and can contain arbitrary references to non-serializable
>     objects and components"
>
>  
> Just a little thinking to share when I studied cform before. I think 
> that it is a bad design to have cform having a reference to its 
> definition.  Once a cform instance is instantiated, it should get rid 
> of its definition and is allowed to modify its structure for more 
> flexible manipulation.
I think that would help. Currently the reference to the definition will 
be used for even the most basic operations though, like creating the SAX 
fragments for field widgets - so it might be somewhat of a bigger task 
to clear that up. Should we take this to the dev list?

>  
>
>
>
>     /So, is it possible?
>
>     Thanks.
>
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>     <ma...@cocoon.apache.org>
>     For additional commands, e-mail: users-help@cocoon.apache.org
>     <ma...@cocoon.apache.org>
>
>


-- 
Ralph Rauscher

 blue elephant systems GmbH
 Wollgrasweg 49
 D-70599 Stuttgart

 Tel   :    (+49) 0711 - 451017 574
 Fax   :    (+49) 0711 - 451017 573
 e-mail:    rra@blue-elephant-systems.com
 Sitz  :    Stuttgart, Amtsgericht Stuttgart, HRB 24106
 Geschäftsführer: Joachim Hörnle, Thomas Gentsch, Holger Dietrich  


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

Re: CForms Serialization

Posted by Rice Yeh <ri...@gmail.com>.
On Wed, Jan 21, 2009 at 6:42 AM, Ralph Rauscher <
rra@blue-elephant-systems.com> wrote:

> Hi,
>
> I have a case where I have a really large form that would require several
> sessions to be valid and I'd like to allow users to persist their work (even
> if the form is invalid) and continue working on it later.
>
> As the cforms binding will throw all kinds of exceptions in this case I
> thought about serializing the Form object using standard Java object
> serialization.
>
> So far Form and the classes it's derived from do not implement
> Serializable, which would be easy to fix. I saw a remark though by Sylvain
> where he mentions
>
> /"a form contains its own data model, which can be serialized, but also
> pointers to its definition, which is shared between form instances and can
> contain arbitrary references to non-serializable objects and components"


Just a little thinking to share when I studied cform before. I think that it
is a bad design to have cform having a reference to its definition.  Once a
cform instance is instantiated, it should get rid of its definition and is
allowed to modify its structure for more flexible manipulation.


>
>
> /So, is it possible?
>
> Thanks.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>