http://documentcloud.github.com/backbone/
It's an MVC framework for the client, really. I'm mentioning it because it is very similar to your thoughts about pub/sub. It hooks events to the data model rather than to each DOM element. I started reading about it this week, highly recommended for inspiration when designing a client framework :) On Fri, Mar 18, 2011 at 12:08 AM, Howard Lewis Ship <[email protected]>wrote: > I monitor a lot of different things but don't often go much deeper > than the home page of most projects. Things still percolate through. > > On Thu, Mar 17, 2011 at 3:27 PM, Inge Solvoll <[email protected]> > wrote: > > 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] > >> > >> > > > > > > -- > 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] > >
