P.S. In an effort to not add even more interfaces(or xml configurations) that we'll need to break out of in tapestry 5 I was pondering using qdox javadoc annotations to mark some of these new methods as Howard had mentioned before, along with the real native annotations of course.
Any thoughts on this one ? They seem to work out fairly well for testng, and since it's one portion of knowledge I'm a little more familiar with after working with it I feel less scared to try and introduce it. It does start to introduce a new component writing style though, which may end up doing more harm than good. On 4/18/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > > As noted by Brian earlier the unit tests are all running happily again > which means that my initial phase of mucking with the render cycle is > finished. (Initial as in there's something there that will probably work but > is probably not completely done changing yet). > > I'd love any feedback people have on it. The parts that I'm not at all > happy with are the tricky little sections in AbstractComponent / > AbstractPage / Shell / (maybe one or two other of our core components ) > where I had to delegate some method calls off to the new "ResponseBuilder" > interface. The solution I have in place isn't ideal by any means, but it may > mostly work for now. I think either some AOP love or breaking interface > changes are the only other options I can think of to give it a better > implementation. I'm going to skip the AOP part for now as I'm guessing it > will require a large mental investment for me to learn it on a level that is > needed to introduce it to tapestry. > > The next phase will ~finally~ be interacting with the client side again. I > have the PropertySelection component working properly with JSON requests via > the dojo ComboBox widget already as a proof of concept(it currently only > switches to client side queries when the component parameter > 'filterOnChange' is set to true), mostly as a starting proof of concept. > > I'm going to probably just hit one thing at a time now (hopefully faster > than what it took to break all of the tapestry internals and slowly > re-fix/factor them again after introducing the ResponseBuilder) , starting > with the <initializtion> element in the @Script component which should > probably connect to window onload events or similar depending on the context > of the response..Ie for normal responses load with window.onload event / > for ajax almost immediately / etc... > > I'm thinking that this will work in a similar fashion to the > ResponseBuilder, a configurable set of script manager sort of API's will be > consulted to determine how these core interactions should be imlpemented > client side scripting wise. (Ie for dojo we'll wrap the entire block with > dojo.event.connect(window, "onload") , if someone feels like imlpementing > the prototype api they can use Event.Observe() instead. ) > > -- > Jesse Kuhnert > Tacos/Tapestry, team member/developer > > Open source based consulting work centered around > dojo/tapestry/tacos/hivemind. http://opennotion.com > -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://opennotion.com
