Thought I'd take a moment out from packing my house to describe what I'd
like to do in 4.1.
Basically, I want to effectively eliminate the rewind cycle. No more
false rendering.
There's going to be a new kind of interaction between the enclosing Form
and the form control components, including For.
As components render, they will register a submit-time callback. The
callback identifies the component (i.e., ComponentAddress) and allows an
additional arbitrary object to be stored as well. Somehow, integrated
into this, will be code in the Form to re-tell the fields what their
element name is. In other words, new method on IFormComponent and IForm.
When a form is triggered, it will no longer render itself; instead it
will use the serialized stream to perform callbacks that reflect the
order in which the fields rendered in the first place.
For and Table will be extended to provide a series of response-time
callbacks during the render, that will be used to restore page state
just before form control components are invoked using callbacks. In
fact, there will probably be a new interface to describe the
relationship between components like For and Foreach and the Form, as
neither will need to have a client-side element id (or generate any
hidden form fields).
This is actually a much simpler design than what's present in 3.0 and
4.0 in many ways; it reflects my growing confidence in what has evolved
out of the DataSqueezer. Further, the reason I felt so strongly about
removing the (ill concieved) Action service was because maintaining that
would prevent this evolution in the Form component.
Things will still work for a volatile For within a Form ... though there
are less guarantees than that the proper objects will be updated. I
suspect that volatile For's will still register callbacks with the Form
for each iteration, but the callback will be a bit different.
Alternately, volatile For components will have no interaction with the
enclosing Form. Still puzzling that out.
If components will no longer need any interaction with the enclosing Form.
It does mean that there'll be a large, MIME encoded object stream for
every form, as a hidden form field. But much of the other logic will go
away. I believe that there will no longer be the possibility of a
StaleLinkException. The situations that may cause StaleLinkExceptions
today may cause NPEs under this scheme.
You can imagine that this object stream would look something like:
<span jwcid="for">
<input jwcid="name"/> <input jwcid="age"/>
</span>
MyPage/for callback <DecodePrimaryKey <Integer 10001>>
MyPage/name callback <UpdateFromParameter 'name'>
MyPage/age callback <UpdateFormParameter 'age'>
MyPage/for callback <DecodePrimaryKey <Integer 12020>>
MyPage/name callback <UpdateFromParameter 'name_0'>
MyPage/age callback <UpdateFormParameter 'age_0'>
etc.
In addition, it will become much less possible to "predict" what the
hidden form fields for a Form component will look like, from a unit
testing angle. The current XML based integration tests will become
impossible to maintain. For my day contract, I'm starting to look a
jWebUnit ... I hope to find a way to merge jWebUnit tests with
Tapestry's mock servlet container. That would be an optimum solution!
I would guess there would be a small performance hit for trivial forms,
but as a form grows in complexity, the advantages of this 4.1 scheme
would grow. This is largely because there would be a single object
stream -> MIME conversion (with all that overhead, including gzip
compression) vs. many small ones (for each value iterated by a For, etc.).
It's funny how, as Tapestry advances, I'm finding it easier and better
to store MORE state on the client than on the server! Although I have
been doing some thinking about a WebObjects style state management
(effectively, a tree of page states for each page), I'm seeing less
urgency in the need for that given the existence of DataSqueezer and
MB's IPrimaryKeyConverter.
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
