I'm all for the single serialized client state concept.
For ajax forms, it does seem problematic, but currently even the addition of
form components has finally been cleared up thanks to your <div> wrapper
around the hidden form input fields. ie :
<form>
<div id="formNameHidden" >
<input type="hidden" name="hidden1" value="foo" />
</div>
I just use my custom AjaxFormSupportImpl to always re-render the targeted
hidden form fields, even if it doesn't necessarily know if the form or every
component is involved in the response. I also added a unique id to the div
so that this is easier(possible) on the client.
I do worry about the size of the client object.
Warning: Getting into the not ~completely~ knowing what I'm talking about
realm, aka talking out of my arse..
Specifically, it's the targeted render "areas" that are a huge impediment
right now, and it doesn't seem likely that you can easily provide a clearer
container/child type of approach without rendering ALL of the unique
component id's involved in the render into the client state. (so that you
really can say ok render at this point, which requires you to step over
components A/B/C, not to render, but just to give them a chance to ensure
the flow isn't broken by skipping things)
Another approach would be to somehow be able to figure this out at render
time in an as yet to be defined efficient manner?
Maybe it is a combination of both. A couple interfaces/tightening of the
For/looping(any container) components and lots of form logic may be enough
to do all of this without having to write all of the id's out to the client.
(Not talking about form id's necessarily.)
Is it bad to write unit tests just to play with a concept? I see id's in
general as being something that would be very nice to have unified, at least
from the outward facing interfaces perspective.
ppftttt...Writing client gui code with a web client sure as sh$% isn't as
easy as doing it natively, but there are a ton of concepts in the render
model that seem to apply. Like containers...I'm sure I could ramble on for
pages and pages.
jesse
On 12/20/05, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:
>
> I hope to abolish the rewind cycle in Tapestry 4.1.
>
> Part of this was to deprecate the ActionLink component and action
> service in 4.0 so that they could be removed in 4.1.
>
> The outline of my approach is that there will be a single hidden form
> field into which a series of objects will be serialized during the
> render. These objects will control the form submission processing and
> will incrementally restore server-side state during the processing.
> Thus the order of operations during the render will DIRECTLY control
> the order of operations during the form submission. Today, we rely on
> the awkward rewind cycle, which is based on re-rendering the form and
> its contents, validating against a list of form element ids.
>
> Rather than many small hidden fields (for each For, If and Hidden,
> component, as well as others) all such data will be accumulated in a
> single bytestream. There is an economy of scale here ... a single
> long serialized bytestream (gzipped and perhaps encrypted, then MIME
> encoded) will be smaller than the sum of many individual hidden fields
> (squeezed with the DataSqueezer, which often uses
> serialization/gzip/MIME anyway).
>
> I'm still struggling, however, with how to properly deal with more
> dynamic ("Ajax") forms. Possibly, we'll support multiple bytestreams
> handled sequentially, to cover dynamically appended forms.
>
>
