You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Kent Tong <ke...@cpttm.org.mo> on 2005/05/08 04:29:27 UTC
Components should maintain their own state unchanged (Was: As a User, which two items would you personally most like to see in the next Tapestry Release?)
Howard Lewis Ship <hlship <at> gmail.com> writes:
>
> Yes, and persistent properties on the client help ensure that the
> appllication state stays associated with the request not the session.
This will help tremendously for component writers. When this becomes
available, why not make the built-in components such as Conditional
and Foreach act like FormConditional (or MindBridge's IF) and
ListEdit (or MindBridge's For)? It should be the component's job
to ensure that its state doesn't change between render and rewind.
The only issue I can see with this approach is that the source will
have to be serializable if Foreach is going to kee the state
unchanged. To solve this problem, this feature can be make optional
at runtime by setting a parameter (just like in .NET people can
enable or disable the "view state" for the data grid).
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Components should maintain their own state unchanged (Was: As a User, which two items would you personally most like to see in the next Tapestry Release?)
Posted by Mind Bridge <mi...@yahoo.com>.
Hi,
> This will help tremendously for component writers. When this becomes
> available, why not make the built-in components such as Conditional
> and Foreach act like FormConditional (or MindBridge's IF) and
> ListEdit (or MindBridge's For)? It should be the component's job
> to ensure that its state doesn't change between render and rewind.
Please see the relevant threads in tapestry-dev -- you will find them
interesting.
This (in the context that requires a rewind) is what is slated for 4.0 and
we are also trying to address the "serializable" (or "primary-key")
questions in an easy manner.
This message may be of a particular interest at the moment, but please see
the entire thread (there are comments from Howards, for example):
http://article.gmane.org/gmane.comp.jakarta.tapestry.devel/5101
----- Original Message -----
From: "Kent Tong" <ke...@cpttm.org.mo>
To: <ta...@jakarta.apache.org>
Sent: Sunday, May 08, 2005 5:29 AM
Subject: Components should maintain their own state unchanged (Was: As a
User, which two items would you personally most like to see in the next
Tapestry Release?)
> Howard Lewis Ship <hlship <at> gmail.com> writes:
>
> >
> > Yes, and persistent properties on the client help ensure that the
> > appllication state stays associated with the request not the session.
>
> This will help tremendously for component writers. When this becomes
> available, why not make the built-in components such as Conditional
> and Foreach act like FormConditional (or MindBridge's IF) and
> ListEdit (or MindBridge's For)? It should be the component's job
> to ensure that its state doesn't change between render and rewind.
>
> The only issue I can see with this approach is that the source will
> have to be serializable if Foreach is going to kee the state
> unchanged. To solve this problem, this feature can be make optional
> at runtime by setting a parameter (just like in .NET people can
> enable or disable the "view state" for the data grid).
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Components should maintain their own state unchanged (Was: As a User, which two items would you personally most like to see in the next Tapestry Release?)
Posted by kranga <kr...@k2d2.org>.
If a component is not part of the form, or if a page has no form, am I
reading correctly that all state will be stuffed into URLs? That would make
terribly long URLs that are not bookmark-capable. Also, you may run over the
URL data size limit fairly easily...
----- Original Message -----
From: "Kent Tong" <ke...@cpttm.org.mo>
To: <ta...@jakarta.apache.org>
Sent: Saturday, May 07, 2005 10:29 PM
Subject: Components should maintain their own state unchanged (Was: As a
User, which two items would you personally most like to see in the next
Tapestry Release?)
> Howard Lewis Ship <hlship <at> gmail.com> writes:
>
> >
> > Yes, and persistent properties on the client help ensure that the
> > appllication state stays associated with the request not the session.
>
> This will help tremendously for component writers. When this becomes
> available, why not make the built-in components such as Conditional
> and Foreach act like FormConditional (or MindBridge's IF) and
> ListEdit (or MindBridge's For)? It should be the component's job
> to ensure that its state doesn't change between render and rewind.
>
> The only issue I can see with this approach is that the source will
> have to be serializable if Foreach is going to kee the state
> unchanged. To solve this problem, this feature can be make optional
> at runtime by setting a parameter (just like in .NET people can
> enable or disable the "view state" for the data grid).
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org