This is funny :) I have been going through the excact same process lately, discovering new ways of organizing my javascript code. I too found that I could get away from the moving target of "this" by applying a more functional style. And that it is quite easy to enforce the separation of public and private by returning an object instance containing only the public methods and fields, and have the public methods call the private methods inside the function context.
I didn't really study this too hard, it just came naturally while working with jQuery and TDD. We have this guy in Norway who wrote an awesome book about test driven javascript, I've learnt a lot from reading his book and attending one of his talks. Most javascript programmers have lots to learn from him, his website here: http://cjohansen.no/. Pub/sub sounds great. The bad reputation of javascript isn't necessarily the language's fault, the bad programmers should also be blamed. We jump right into low level stuff like browser differences and events without thinking too much about creating higher level abstractions. I've been looking into backbone.js, a very good example of an abstraction that REALLY makes a difference in client programming. Do you guys draw inspiration from sources like that? On Thu, Mar 17, 2011 at 5:56 PM, Howard Lewis Ship <[email protected]> wrote: > 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] > >
