On 11/27/05, Howard M. Lewis Ship <[EMAIL PROTECTED]> wrote: > Thought I'd take a moment out from packing my house to describe what I'd > like to do in 4.1.
Thanks, that's always interesting to know where the project may be directed and have a good journey to your new home > Basically, I want to effectively eliminate the rewind cycle. No more > false rendering. One thing i would have had even in 4.0 > 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. Have you thought about security implication? Just a guess... > 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. > 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! That's would mean a path to follow even for application development testing? > 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.). Does the portlet side of Tapestry be affected by this choice? Almost in every portlet I've done or seen there's a small form... > 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. I've to admit, as a global note, I'm not very comfortable with storing states (and consequently what relates to states) on the client but i don't know so much (yet) of Tapestry internals so i just guess if this could lead to wasting more bandwidth then what is actually needed if the form MIME stream grows in size and/or in numbers per page, or maybe this could be over headed by the typical page animations/graphics/media goodness. -- Massimo http://meridio.blogspot.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
