Working with Backbone.js : ok to have static reference to current EventContext ?

[Nathan Stults]

Hello again,

 

I am working on integrating Backbone.js into my Sammy.js app – Sammy.js for providing overall application structure and runtime and Backbone.js for encapsulating domain logic – put the two together and  you have one powerful client side app framework. Very exiting.

 

Anyway, the problem I’m playing with at the moment is how to provide Sammy’s EventContext to Backbone’s models and views, as the EventContext seems to be the access point to all of Sammy’s mystical powers, but is transient. What I’m considering doing at the moment is simply setting

 

app.currentEventContext = this

 

in each of my routes, and then Backbone models and views, which will have access to the global Sammy app, can do things like

 

window.app.currentEventContext.render(blah,blah).then(…)

 

I do actually have a question, which is, is this a safe and appropriate way to treat event contexts? Is my assumption that only one event context will be in scope at any given time a safe assumption, or are there any concurrence issues I would need to consider?

 

Also, has anyone on this list already created an app with both Backbone.js and Sammy.js and already fleshed out some patterns that work well? I’m just now getting started on this, and if anyone has blazed a trail already, I’d love to hear your experiences.

 

[Brandon Keepers]

I've also been experimenting with incorporating backbone into a Sammy app.

Sammy's rendering has never quite felt right to me.  It always felt like the "controller" knows too much about and is too dependent on the view. I'm also not crazy about the stock backbone views.  It's closer, but I don't like how you have to specify the root element and it gets created when the view is initialized, instead of just letting a template handle that.

Instead, I'm going to implement my own view framework that combines the best parts of backbone and Sammy's view support.

Here are the responsibilities that I think the view framework should handle:

* present one or more models for a template

* render the template (using a configurable engine)

* insert the template into the DOM

* handle DOM events

I've started on an implementation that I hope will accomplish those goals, but not get too heavy.  I'll post more about it in the next day or so when I have something working.

Thanks,

=b

-- 
You received this message because you are subscribed to the Google Groups "Sammy.js" group.
To post to this group, send email to sam...@googlegroups.com.
To unsubscribe from this group, send email to sammyjs+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sammyjs?hl=en.

[Nathan Stults]

Sounds great. If it ends up on github, please do post a link, I'd like to follow along. I agree the views in backbone can be a bit awkward. Looking forward to seeing what you come up with.

Thanks,

Nathan Stults

[Aaron Quint]

I'm definitely interested to see what you come up with, too, Brandon!
I'm also curious to see how I can improve on the current state of
Sammy. What do you see as too much view in the controller?

In terms of extracting the magic of the EventContext, you're probably
actually talking about the RenderContext, and though I wouldn't
necessarily suggest it, it's just a first class JS prototype and you
could initialize it on you're own

var context = new Sammy.RenderContext(new Sammy.EventContext(app,
'get', 'path'))
context.render('mytemplate.mustache')
.replace('#main')

There is a really good reason to have separate EventContext's per
route run. One, it is really an object and having it contain its own
path, params, etc. makes sense from an OOP or a OOP perspective. Two,
route handlers are really similar to DOM event handlers. Even though
in a basic sammy app, you're maintaing state in the form of a #hash,
unlike the classic server request/response the handlers for these URLs
are actually evented. For example, you could start out at '/#/' and
that would fire the route matching that path, if you then quickly
change the URL to '#/somethingelse' the somethingelse route would be
fired simultaneously whether or not the original route was finished
executing. With a single 'currentX' var, theres a strong chance of
having the current not actually be able to correctly represent the
state of the app.

Either way I'm excited about the prospect of integrating with Backbone
so any experiences/feedback you can share, please do!
--AQ

[max williams]

I have to say that I tend to agree with Brandon's views (no pun
intended). However I can't really put my finger on what it is.

It may be that Sammy's current view rendering seems too similar to the
way views are rendered in a Rails app, and effectively emulates a
traditional request response cycle. I don't think that this is
necessarily a useful pattern since JS apps are stateful...

Just my 2cents.

Max

[Nathan Stults]

I think you did put your finger on it. Pure MVC, as it is implemented in Rails for example, was absolutely designed for a stateless environment. You don't really have 'user interactions' so far as the presentation tier is concerned, you just have requests and responses.

Since Sammy.js inherits the pure MVC approach from Sinatra, using just Sammy.js you have to write all the plumbing code to coordinate user interactions via events yourself. As there is no obvious place to put all this plumbing, you have all these exposed wires strung out across your code (or at least I do). Backbone's views aren't really views but are more like Presentation Models (http://martinfowler.com/eaaDev/PresentationModel.html) and more suited to a stateful environment. As ironic as it may be, particularly for me as I just left that world for this one, it may be useful to look at some of the patterns evolved to suit stateful applications, such as MVP and WPF's MVVM and see if they have anything that could inform the evolution of these client side browser frameworks.

Just my 2cents.

Max

> > I am working on integrating Backbone.js into my Sammy.js app -

> > Sammy.js for providing overall application structure and runtime and

> > Backbone.js for encapsulating domain logic - put the two together

> > and  you have one powerful client side app framework. Very exiting.
> >
> > Anyway, the problem I'm playing with at the moment is how to provide
> > Sammy's EventContext to Backbone's models and views, as the
> > EventContext seems to be the access point to all of Sammy's mystical
> > powers, but is transient. What I'm considering doing at the moment
> > is simply setting
> >
> > app.currentEventContext = this
> >
> > in each of my routes, and then Backbone models and views, which will
> > have access to the global Sammy app, can do things like
> >

> > window.app.currentEventContext.render(blah,blah).then(...)

[Nathan Stults]

Ok - so it sounds like should not do what I am doing :) I don't really need the RenderContext anyway, I'm handling params and loading data and things in my Sammy routes outside Backbone, I'm just using Backbone to do the rendering. As the rendering plugin mechanism is implemented on helpers that extend RenderContext, I was just trying to get at the templating code without having to make any modifications to Sammy.js. As the template plugins don't actually use anything from the RenderContext, I wonder if it would make more sense for their entry points (i.e. handlebars(blah,blah)) to be at the app level instead of the RenderContext level?

-----Original Message-----
From: sam...@googlegroups.com [mailto:sam...@googlegroups.com] On Behalf Of Aaron Quint
Sent: Tuesday, October 19, 2010 6:36 AM
To: sam...@googlegroups.com
Subject: Re: [sammy.js] Working with Backbone.js : ok to have static reference to current EventContext ?

> I am working on integrating Backbone.js into my Sammy.js app -

> Sammy.js for providing overall application structure and runtime and

> Backbone.js for encapsulating domain logic - put the two together and 

> you have one powerful client side app framework. Very exiting.
>
> Anyway, the problem I'm playing with at the moment is how to provide
> Sammy's EventContext to Backbone's models and views, as the
> EventContext seems to be the access point to all of Sammy's mystical
> powers, but is transient. What I'm considering doing at the moment is
> simply setting
>
> app.currentEventContext = this
>
> in each of my routes, and then Backbone models and views, which will
> have access to the global Sammy app, can do things like
>

> window.app.currentEventContext.render(blah,blah).then(...)

[Aaron Quint]

I see where you all are coming from, but on some level I guess I
disagree or at least side-step. On a fundemental level evented/ajax
apps are actually stateless, or rather they have no single state, but
n states. Sammy is just trying to make it seem like it has state, or
at least help you make a consistent state possible. From a view
perspective this means that at any given state, you probably actually
have to check the state of multiple elements and update accordingly.
What I end up doing is wrapping individual checks into helpers and
then executing them within the relevant routes. For example:

this.helpers({
setHeader: function(title) {
// do the dom or rendercontext manip on the title
},
loadPhoto: function(photo_id) {
// do the dom or rendercontext manip on the photo
}
});

this.get('#/:photo_id', function() {
this.setHeader('Photo');
this.loadPhoto(this.params.photo_id);
});

The real difference between here and any server side framework is that
were not loading data and shoving it into a stream of HTML, we're
actually manipulating the contents of an existing page and can do it
peacemeal or all at once. I guess I also never thought that Sammy
should really have a high level view framework as part of its core.
RenderContext, EventContext and the template helpers are really low
level, they just ease fetching data/templates and turning them into
DOM elements. The actual 'how should I present my data from the server
and how should I then consistently and easily template it' question is
really up to you. I would love to see a plethora of pluggable view
frameworks that work in completely different ways but could be built
on top of the core sammy methods. I know choco
(http://github.com/ahe/choco) has its own way of doing things, and
clearly backbone does as well.

--AQ

On Tue, Oct 19, 2010 at 11:54 AM, Nathan Stults

[Nathan Stults]

I agree 100% - Sammy does not need such a framework in its core, but provide the low level framework as it does now and, as you say, lots of nice helpers to make everyone feel at home. Users of Sammy can plug in the view, or view-model or presentation-model or whatever framework of choice, or none at all and Sammy should be a helpful, friendly host to such other frameworks for the folks that bring them to the party. I am implementing my backbone layer as a Sammy plugin and that seems to be working pretty well.

[max williams]

I'd say that you are talking about a different version of 'state'
there Aaron, which could be possibly be described as 'visual state'.
The 'state' that I was referring to is more of a 'data state'. I think
that an Ajax app can absolutely be stateful in this sense if you are
using something like backbone.js or js-model.

It is possible to create a Sammy app that simply acts as a proxy to
your server, and is therefore locked into the request response cycle.
The alternative is to store a local copy of your app's state, which
you can manipulate as you please.

Not quite sure this adds anything, but I feel this is a very
interesting discussion to be having. Looking forward to Brandon's
stuff :)

Max

[Nathan Stults]

In case anyone else is being heretical and wanting to create contexts themselves, this did not work for me:

var context = new RenderContext(new SammyContext(...));

because 'helper' methods (specifically the rendering plugin helpers) weren't attached to the object, perhaps not surprisingly. However, this did work for me:

var context = new app.context_prototype(app);

Where 'app' is a reference to the Sammy application.

So now I wrapped that in a method called createContext() that I call from within my Backbone models and views when I need Sammy services, as it was pointed out by Aaron that there may be multiple contexts in play at any given time, so trying to hold a reference to currentContext would be dangerous.

Thanks,

Nathan

-----Original Message-----
From: Nathan Stults
Sent: Tuesday, October 19, 2010 8:58 AM
To: 'sam...@googlegroups.com'
Subject: RE: [sammy.js] Working with Backbone.js : ok to have static reference to current EventContext ?

Ok - so it sounds like should not do what I am doing :) I don't really need the RenderContext anyway, I'm handling params and loading data and things in my Sammy routes outside Backbone, I'm just using Backbone to do the rendering. As the rendering plugin mechanism is implemented on helpers that extend RenderContext, I was just trying to get at the templating code without having to make any modifications to Sammy.js. As the template plugins don't actually use anything from the RenderContext, I wonder if it would make more sense for their entry points (i.e. handlebars(blah,blah)) to be at the app level instead of the RenderContext level?

-----Original Message-----
From: sam...@googlegroups.com [mailto:sam...@googlegroups.com] On Behalf Of Aaron Quint
Sent: Tuesday, October 19, 2010 6:36 AM
To: sam...@googlegroups.com
Subject: Re: [sammy.js] Working with Backbone.js : ok to have static reference to current EventContext ?

> I am working on integrating Backbone.js into my Sammy.js app -

> Sammy.js for providing overall application structure and runtime and

> Backbone.js for encapsulating domain logic - put the two together and

> you have one powerful client side app framework. Very exiting.
>
> Anyway, the problem I'm playing with at the moment is how to provide
> Sammy's EventContext to Backbone's models and views, as the
> EventContext seems to be the access point to all of Sammy's mystical
> powers, but is transient. What I'm considering doing at the moment is
> simply setting
>
> app.currentEventContext = this
>
> in each of my routes, and then Backbone models and views, which will
> have access to the global Sammy app, can do things like
>

> window.app.currentEventContext.render(blah,blah).then(...)