You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Howard Lewis Ship <hl...@gmail.com> on 2011/03/17 17:56:33 UTC
[DISCUSSION] Client-side pub/sub
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [DISCUSSION] Client-side pub/sub
Posted by François Facon <fr...@atosorigin.com>.
Generic and efficient Pub/Sub syteme will be very helpfull for listening to
notifications from a server-side push system.
I find this map today
http://addyosmani.com/blog/tools-for-jquery-application-architecture-the-printable-chart/
and the related link to pub/sub sytem
jQuery pub/sub systeme
https://gist.github.com/661855
http://millermedeiros.github.com/js-signals/
http://weblog.bocoup.com/publishsubscribe-with-jquery-custom-events
http://higginsforpresident.net/js/static/jq.pubsub.js
this one is more related to cross domain
http://www.openajax.org/member/wiki/OpenAjax_Hub_2.0_Specification_Publish_Subscribe_Overview
2011/3/18 Inge Solvoll <in...@gmail.com>
> 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 <hlship@gmail.com
> >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 <in...@gmail.com>
> > 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 <hl...@gmail.com>
> > 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: dev-unsubscribe@tapestry.apache.org
> > >> For additional commands, e-mail: dev-help@tapestry.apache.org
> > >>
> > >>
> > >
> >
> >
> >
> > --
> > 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: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
>
Re: [DISCUSSION] Client-side pub/sub
Posted by Inge Solvoll <in...@gmail.com>.
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 <hl...@gmail.com>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 <in...@gmail.com>
> 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 <hl...@gmail.com>
> 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: dev-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: dev-help@tapestry.apache.org
> >>
> >>
> >
>
>
>
> --
> 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
Re: [DISCUSSION] Client-side pub/sub
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 <in...@gmail.com> 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 <hl...@gmail.com> 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: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
--
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [DISCUSSION] Client-side pub/sub
Posted by Inge Solvoll <in...@gmail.com>.
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 <hl...@gmail.com> 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
Re: [DISCUSSION] Client-side pub/sub
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
This looks very good to me. I'd just ask to keep (almost total) backward
compatibility, as JavaScript is way more difficult to notice and adapt
code to API changes.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org