I would suggest another approach to that one:
since multiple html fields with same name attribute come up as an java
array, I would suggest adding a new form-fields grouping component which
will be responsible for generating the callback-hidden, so not one but
multiple hidden, all with the same name, will contain the call back info.
the group component may then be updated as a whole...
You have problem only when adding a new group (ie when grouping fields
inside a For iteration, which changes on an AJAX request), on which case
you have to refresh the whole hidden-div.
Cheers,
Ron
Jesse Kuhnert wrote:
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
