As you might tell from my blog, I've been doing a lot of thinking over the last few days (and weeks, and months) about what I would like to see in the JavaScript support for Tapestry 5.3/5.4.
First note the split releases: I think it will take more than one release to get it "right". I'd like to introduce some stable ideas in 5.3 and build on them in 5.4. My blog discusses the packaging/namespaceing approach: http://tapestryjava.blogspot.com/2011/03/better-namespacing-in-javascript.html I'm prototyping this inside TapX and seeing great results. More readable, more succinct, easier to build and debug. You don't get tripped up over "this" because "this" is no longer relevant; it's a more functional style of programming. I think another area to scope out would be a simple publish/subscribe system running on the client side. Currently, we are "abusing" the event system to deal with flow of control issues, such as requesting fields to perform validation checks, or notifying the world that a Zone has updated its content. I think there some value in separating these two things, so that we can publish a notification about an element without firing an event on that element. One benefit is that it helps de-couple logic from the particular JavaScript substrate (my term: currently the substrate is Prototype/Scripaculous). A second benefit is that it should be possible to have notifications that are about other abstractions besides elements. Third, a client-side pub-sub system should become a very natural way of hooking together a server-side push system into a Tapestry application in a uniform way. I haven't done too much thought about what this will look like exactly. I kind of like the idea that when you register a listener for a notification, you receive an object with which you can pause and unpause notifications (much like Prototype 1.7's on() function). Do you register a notification by a string name or by an arbitrary object? Are notifications in some kind of hierarchy? Perhaps for notifications on DOM elements, there's some thought of bubbling (or a more generic concept of a filter between the publisher of the notification and the listeners for the notification). I'll jot down my thoughts on an API shortly. Have to get to work now! -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
