I think this sounds like a huge step in the right direction :) I had a couple of thoughts that I wanted to chime in with.
The callback identities would be nice to have applied to links as well as forms. This would enable similar interactions with For/Foreach/etc outside the context of a form, which would be as important for my use-cases as those instances where a form is involved. Maybe it is only in how the identifiers are stored that is different in the form scenerio? Continuing on the identifier logic, someone else using what I think is Web Objects (could be something..I always confuse the two) was giving me a hard time about friendly urls. What you do here could concievably make them even friendlier? Ie http://<yourhost>/app/UserAdmin/EditUserPage/1134 Would take you to the edit page for that particular user. Or something...That doesn't really mean anything for components I guess :/ In regard to client-side state management, I saw your new work with the swf files, which is what I'm assuming you were referring to in regard to WO. The dojo guys just finished adding in a new storage api system based off a similar concept. Though I'm sure it's too new to reliably use right away, for my uses it would be incredibly helpful. Basically tacos is fairly useless in certain situations if you try and use client-side state management because it doesn't go back and refresh all of your href links everywhere. The storage subsystem could hold this sort of global state in a nice little area for us :) Here is a link to their swf-based storage impl test http://archive.dojotoolkit.org/nightly/tests/storage/test_storage.html. In regard to jWebUnit, I was using it to test some parts of my app a long time ago but eventually ditched it in frustration with them not syncing up with whatever xml libraries were in use at the time.. (Some bug having to do with cloning xml nodes) It's probably fixed now...I also just yesterday started playing with htmlunit in tacos. It's all checked into cvs, but it starts up a jetty container within the code and then hits one of my pages..For my purposes it's not really going to be useable because mozilla's Rhino java-based javascript engine interpreter isn't quite up to date enough to handle all of the insanity involved in the dojo packages. You may want to check htmlunit out as well though..I've used both now (htmlunit very very slightly), but I like what htmlunit has to offer more so far. I do still have a testing solution available via a FF plugin that allows spidering of pages and unit test assertions (similar to selenium, only not fundamentally flawed the way it is..) , it's just not really as much an automated solution as would be nice :( Perhaps theirs an easy way to run a headless version of mozilla. heh. BTW, I think the grid widget (component) is going to get a lot of attention on wednesdays 2pm est dojo irc meeting (freenet #dojo) if anyone was interested in the goings-on of that work. jesse 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. > > 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] > >
