[ANN] Sammy.js 0.3.0 Released

[Aaron Quint]

Hey All

Its been almost a month in progress, but the next branch has finally
been brought into master. (yay!)

Theres a blog post here:
http://www.quirkey.com/blog/2009/09/30/sammy-0-3-0-released-i-gotta-right-to-swing/

Regarding this list and the community there are two big announcements:

1 - Plugins

I've started an official plugin repository. If you have an awesome
piece of code or a template engine, now theres a way to create a
plugin, so that any Sammy user can easily include it in their app. I'd
love contributions from the community or any suggestions for cool
plugins.

2 - Resources/Links page

I've added a "Resources" page to the github pages:
http://code.quirkey.com/sammy/resources.html

If theres a link/blog post/project that I didn't put up, or something
you create that you think should be up there - let me know!

Thanks to everyone who helped with this release!

Heres a full CHANGELOG (pretty big):

== 0.3.0 [09/28/09]

New:
- Sammy.Application#use() takes an app function and applies it to
the current app. This is the entry point for Sammy Plugins. See docs
at: http://code.quirkey.com/sammy/docs/plugins.html
- New system for repository structure, minified files are placed in
lib/min/ version numbers are appended to minified files
- Sammy.EventContext#partial() is template engine agnostic and calls
the template engine method based on the extension of the file you're
trying to render.
- New official Sammy.Cache plugin provides simple client side caching
- Sammy.EventContext#redirect() can take any number of arguments
that are all joined by '/'
- Sammy.Application#refresh() will re-run the current route

Changes:
- Removed John Resig's Class() inheritance code/style in favor of
doing prototypical inheritance and using $.extend()
- Sammy.Application bind() and trigger() now use jQuery's built in
namespacing. This means that a Sammy application can now catch events
like clicks and other events that bubble up or are triggered on the
Sammy.Application#element()
- Sammy.log and Sammy.addLogger are top level access to logging and
adding additional logging paths. Sammy.Application#bindToAllEvents()
replaces the functionality for the former addLogger() method
- the app functions and route callbacks both take _this_ as the first argument
- $.srender and template() are no longer part of the sammy.js and
are instead included in the Sammy.Template plugin
lib/plugins/sammy.template.js
- Routes are saved and looked up in order of definition instead of
shortest first (May break existing applications that use RegExp based
routing)
- Made the parse query more uniform with the rest of the code base
- Sammy.Object#toString() wont include functions unless you
explicitly want them

Fixes:
- Fixed redirect() handling in post routes
- Fixed param parsing for form submission where there were multiple
params with the same name

--AQ

Aaron Quint
http://www.quirkey.com

[Marak Squires]

Looking good Aaron! Can't wait to see whats next.

$.srender and template() make way more sense as plugins then being
part of the core.

I still don't think _checkLocation should be the primary way of
navigating though routes though. I'd rather see runRoute() be event
driven then interval driven. The problem obviously is the back button
working in the browser but I think _checkLocation could still be used
to trap this condition and the primary routing mechanism could be done
through an IOC container.


-Marak Squires

On Sep 30, 11:18 am, Aaron Quint <aa...@quirkey.com> wrote:
> Hey All
>
> Its been almost a month in progress, but the next branch has finally
> been brought into master. (yay!)
>

> Theres a blog post here:http://www.quirkey.com/blog/2009/09/30/sammy-0-3-0-released-i-gotta-r...

[Aaron Quint]

Marak

I think the next big thing besides expanding the plugin repository is
reworking the checkLocation piece. My thinking now is that there will
be a seperate plugin (included by default) that handles the hashchange
as an event. It will use the native onhashchange event in browsers
that support it (latest IE, Firefox, Safari) and fall back to a single
setInterval() per page instead of per-app. I see what you're saying
with the not wanting to use an interval at all, but I really really
like the ability to just change the hash/url in the location bar and
have it the app react.

Thanks for the feedback! I'd love to keep this discussion going,

--AQ

Aaron Quint
http://www.quirkey.com

[Todd Willey]

Thanks, I'm super-excited about this! More comments/questions inline.

On Wed, Sep 30, 2009 at 11:18 AM, Aaron Quint <aa...@quirkey.com> wrote:
>
> Hey All
>
> Its been almost a month in progress, but the next branch has finally
> been brought into master. (yay!)
>
> Theres a blog post here:
> http://www.quirkey.com/blog/2009/09/30/sammy-0-3-0-released-i-gotta-right-to-swing/

Very helpful, esp. the bind/trigger example. I'm excited about
screencasts as a marketing tool as well.

>
> Regarding this list and the community there are two big announcements:
>
> 1 - Plugins
>
> I've started an official plugin repository. If you have an awesome
> piece of code or a template engine, now theres a way to create a
> plugin, so that any Sammy user can easily include it in their app. I'd
> love contributions from the community or any suggestions for cool
> plugins.

In the blog post, it has you including the plugin's javascript (after
sammy.js) and then you are calling it inside an application callback.
Does this mean each plugin has to be enabled per-application on a
page, or is there some way to enable it once for all applications on a
page?

>
> 2 - Resources/Links page
>
> I've added a "Resources" page to the github pages:
> http://code.quirkey.com/sammy/resources.html
>
> If theres a link/blog post/project that I didn't put up, or something
> you create that you think should be up there - let me know!
>
> Thanks to everyone who helped with this release!
>
> Heres a full CHANGELOG (pretty big):
>
> == 0.3.0 [09/28/09]
>
> New:
>  - Sammy.Application#use() takes an app function and applies it to
> the current app. This is the entry point for Sammy Plugins. See docs
> at: http://code.quirkey.com/sammy/docs/plugins.html
>  - New system for repository structure, minified files are placed in
> lib/min/ version numbers are appended to minified files
>  - Sammy.EventContext#partial() is template engine agnostic and calls
> the template engine method based on the extension of the file you're
> trying to render.

I end up using the native JQuery ajax methods load/get/post instead of
srender. Moving this into a plugin is a plus, I think.

Thanks! Looking forward to giving it a test run.

>
> --AQ
>
> Aaron Quint
> http://www.quirkey.com
>
> >
>

--
CONFIDENTIALITY NOTICE: This email is for sole use of intended
recipient(s). Unauthorized use is prohibited.

[Marak Squires]

Aaron -

I agree with the functionality of being able to manually change the location.hash is a good thing and I wouldn't want to remove it completely by any means.

onhashchange isn't fully implemented cross-browser yet, but it would be great to start including future support for this.

The only thing that bothers me a bit is the idea of using a 50ms polling interval to constantly check if the application has entered a new state. It seems a bit "dirty", but perhaps it is the best choice based on the nature of JavaScript and the browser? Ideally you would want to have everything properly event driven, but the lack of onhashchange support causes the problem.

On a bit of a side note I am working on a similar project to Sammy and I think there is nothing but room for improvement in this area of software development. I think a lot of the work I am doing could help Sammy and vice versa. I will be around the IRC to continuing discussing this further.

-Marak
(aka JimBastard)

On Thu, Oct 1, 2009 at 7:57 PM, Todd Willey <to...@rubidine.com> wrote:

Thanks, I'm super-excited about this!  More comments/questions inline.

On Wed, Sep 30, 2009 at 11:18 AM, Aaron Quint <aa...@quirkey.com> wrote:
>
> Hey All
>
> Its been almost a month in progress, but the next branch has finally
> been brought into master. (yay!)
>
> Theres a blog post here:

>in July

[Aaron Quint]

Hey Todd

Replies inline:

On Thu, Oct 1, 2009 at 7:57 PM, Todd Willey <to...@rubidine.com> wrote:
>

> Thanks, I'm super-excited about this!  More comments/questions inline.
>
> On Wed, Sep 30, 2009 at 11:18 AM, Aaron Quint <aa...@quirkey.com> wrote:
>>
>> Hey All
>>
>> Its been almost a month in progress, but the next branch has finally
>> been brought into master. (yay!)
>>
>> Theres a blog post here:
>> http://www.quirkey.com/blog/2009/09/30/sammy-0-3-0-released-i-gotta-right-to-swing/
>
> Very helpful, esp. the bind/trigger example.  I'm excited about
> screencasts as a marketing tool as well.
>

Please let me know if you have other ideas/things you want to see more of.

>>
>> Regarding this list and the community there are two big announcements:
>>
>> 1 - Plugins
>>
>> I've started an official plugin repository. If you have an awesome
>> piece of code or a template engine, now theres a way to create a
>> plugin, so that any Sammy user can easily include it in their app. I'd
>> love contributions from the community or any suggestions for cool
>> plugins.
>
> In the blog post, it has you including the plugin's javascript (after
> sammy.js) and then you are calling it inside an application callback.
> Does this mean each plugin has to be enabled per-application on a
> page, or is there some way to enable it once for all applications on a
> page?
>

Yes, currently you would have to enable them in every application. If
you're really keen on extending everything you can extend the
Sammy.Application.prototype or the Sammy.EventContext.prototype. I'd
make this a last resort as you might get into trouble with conflicts
down the line. An easy thing to do though is to build a meta-plugin
that includes many other plugins and just include that every time.
e.g.

var MetaPlugin = function(app) {
app.use(Sammy.Template);
app.use(Sammy.Cache);
app.use(MyOtherPlugin);
};

$.sammy(function(app) {
app.use(MetaPlugin);
});

I've also thought about creating a bundler kind of like the way
jquery-ui works, where you select the plugins/packages you want and it
could concatenate them into a single file (maybe even include jquery,
too). Maybe a little early, but down the line it could be cool.

Awesome! Let me/this list know how it goes or if you have questions/bug reports.

--AQ

[Aaron Quint]

Hey Marak

I think we're on the same page here. The key will be that the the
polling will just fire the event, so maybe there will be a
configuration option that turns off polling completely, and you 're
responsible for firing the hashchange event. In general I dont think
setInterval is too evil. I think relying on it exclusively in general
instead of events and having hundreds of them on a page could cause
issues, but I think a single one, polling a single value wont really
cause any harm.

--AQ

[Marak Squires]

Aaron -

Any suggestions on how to detect if hashchange is a viable event? I've researched a bit and all I could find were people checking the browser version and maintaining a list of browsers which supported it.

-Marak

[Todd Willey]

On Thu, Oct 1, 2009 at 11:04 PM, Aaron Quint <aa...@quirkey.com> wrote:
>
> Hey Todd
>
> Replies inline:
>
> On Thu, Oct 1, 2009 at 7:57 PM, Todd Willey <to...@rubidine.com> wrote:
>>
>> Thanks, I'm super-excited about this!  More comments/questions inline.
>>
>> On Wed, Sep 30, 2009 at 11:18 AM, Aaron Quint <aa...@quirkey.com> wrote:
>>>
>>> Hey All
>>>
>>> Its been almost a month in progress, but the next branch has finally
>>> been brought into master. (yay!)
>>>
>>> Theres a blog post here:
>>> http://www.quirkey.com/blog/2009/09/30/sammy-0-3-0-released-i-gotta-right-to-swing/
>>
>> Very helpful, esp. the bind/trigger example.  I'm excited about
>> screencasts as a marketing tool as well.
>>
>
> Please let me know if you have other ideas/things you want to see more of.

* Using partial, esp with a callback param to update an area different
from the app's $element().
* Saving params from a post and redirecting to a get, to insert the
change into the page history
* Using $element().trigger('changed') if you update content manually
(not partial()), esp if you're adding a form.

[Todd Willey]

Maybe the first time .run() is called, before it boots the application
it could set a hashchange listener,
document.location.href='#/hashtest', then window.history.go(-1) and if
the listener gets called in that process it sets a flag. Then the
listener is removed and the app continues booting normally. It is a
little invasive, but might have potential.

Maybe a plugin could do it. bind('run') in the app when included.
When called do the navigation trick. clearInterval on app._interval
if hashchange works, and set up the listener.

-todd[1]

[Marak Squires]

Todd -

Wouldn't that result in url bar flickering for a moment as it ran this test? I thought up the same solution but really didn't think it was viable.

-Marak

[Todd Willey]

It would, that's why I called it invasive. I just think testing for
actual behavior is better than matching a browser version, since there
are times such a list is guaranteed to be incomplete. That being
said, I don't really mind the polling. I've been using sammy for
about 3 months and haven't experiences any page slowdown yet, though
if I had I suspect it might be one of my first sources of
optimization.

-todd[1]

[Aaron Quint]

I'm pretty sure theres a way to check for the presence of system
events as properties of the window:

e.g. if (window.onhashchange)

Either way, I need to do some more research on this,

--AQ

Aaron Quint
http://www.quirkey.com

[Marak Squires]

Until hashchange is fully supported the polling is inevitable. Having one poll running at 50ms to detect state changes is a necessary evil for now.

-Marak

[Todd Willey]

Nice! $form keeps getting added to my posts when I call
params.toHash(). Not a big deal, but not expected, either.