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.
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
$.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:
> 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.
> 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
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
On Thu, Oct 1, 2009 at 7:48 PM, Marak Squires <marak.squi...@gmail.com> wrote:
> 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!)
>> 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.
>> 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
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?
> 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.
> - 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
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.
On Thu, Oct 1, 2009 at 7:57 PM, Todd Willey <t...@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
> 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?
> > 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.
> > - 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
> Thanks! Looking forward to giving it a test run.
>> 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.
>> 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.
>> - 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
> Thanks! Looking forward to giving it a test run.
Awesome! Let me/this list know how it goes or if you have questions/bug reports.
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.
On Thu, Oct 1, 2009 at 8:53 PM, Marak Squires <marak.squi...@gmail.com> wrote:
> 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 <t...@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
>> 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?
>> > 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.
>> > - 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
>> Thanks! Looking forward to giving it a test run.
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.
On Thu, Oct 1, 2009 at 11:07 PM, Aaron Quint <aa...@quirkey.com> wrote:
> 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
> On Thu, Oct 1, 2009 at 8:53 PM, Marak Squires <marak.squi...@gmail.com>
> wrote:
> > 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 <t...@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
> >> 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?
> >> > 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.
> >> > - 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
> >> Thanks! Looking forward to giving it a test run.
>> 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.
>>> 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.
> 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.
>>> 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.
>>> - 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
>> Thanks! Looking forward to giving it a test run.
> Awesome! Let me/this list know how it goes or if you have questions/bug reports.
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.
On Fri, Oct 2, 2009 at 10:31 AM, Marak Squires <marak.squi...@gmail.com> wrote:
> 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
> On Thu, Oct 1, 2009 at 11:07 PM, Aaron Quint <aa...@quirkey.com> wrote:
>> 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
>> On Thu, Oct 1, 2009 at 8:53 PM, Marak Squires <marak.squi...@gmail.com>
>> wrote:
>> > 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 <t...@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
>> >> 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?
>> >> > 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.
>> >> > - 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
>> >> Thanks! Looking forward to giving it a test run.
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.
On Fri, Oct 2, 2009 at 10:39 AM, Todd Willey <t...@rubidine.com> wrote:
> 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]
> On Fri, Oct 2, 2009 at 10:31 AM, Marak Squires <marak.squi...@gmail.com>
> wrote:
> > 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
> > On Thu, Oct 1, 2009 at 11:07 PM, Aaron Quint <aa...@quirkey.com> wrote:
> >> 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
> >> On Thu, Oct 1, 2009 at 8:53 PM, Marak Squires <marak.squi...@gmail.com>
> >> wrote:
> >> > 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 <t...@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
> >> >> 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?
> >> >> > 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.
> >> >> > - 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
> >> >> Thanks! Looking forward to giving it a test run.
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.
On Fri, Oct 2, 2009 at 10:42 AM, Marak Squires <marak.squi...@gmail.com> wrote:
> 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
> On Fri, Oct 2, 2009 at 10:39 AM, Todd Willey <t...@rubidine.com> wrote:
>> 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]
>> On Fri, Oct 2, 2009 at 10:31 AM, Marak Squires <marak.squi...@gmail.com>
>> wrote:
>> > 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
>> > On Thu, Oct 1, 2009 at 11:07 PM, Aaron Quint <aa...@quirkey.com> wrote:
>> >> 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
>> >> On Thu, Oct 1, 2009 at 8:53 PM, Marak Squires <marak.squi...@gmail.com>
>> >> wrote:
>> >> > 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 <t...@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
>> >> >> 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?
>> >> >> > 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.
>> >> >> > - 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
>> >> >> Thanks! Looking forward to giving it a test run.
On Fri, Oct 2, 2009 at 11:15 AM, Todd Willey <t...@rubidine.com> wrote:
> 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]
> On Fri, Oct 2, 2009 at 10:42 AM, Marak Squires <marak.squi...@gmail.com> wrote:
>> 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
>> On Fri, Oct 2, 2009 at 10:39 AM, Todd Willey <t...@rubidine.com> wrote:
>>> 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]
>>> On Fri, Oct 2, 2009 at 10:31 AM, Marak Squires <marak.squi...@gmail.com>
>>> wrote:
>>> > 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
>>> > On Thu, Oct 1, 2009 at 11:07 PM, Aaron Quint <aa...@quirkey.com> wrote:
>>> >> 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
>>> >> On Thu, Oct 1, 2009 at 8:53 PM, Marak Squires <marak.squi...@gmail.com>
>>> >> wrote:
>>> >> > 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 <t...@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
>>> >> >> 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?
>>> >> >> > 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.
>>> >> >> > - 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
>>> >> >> Thanks! Looking forward to giving it a test run.
On Fri, Oct 2, 2009 at 11:15 AM, Todd Willey <t...@rubidine.com> wrote:
> 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]
> On Fri, Oct 2, 2009 at 10:42 AM, Marak Squires <marak.squi...@gmail.com>
> wrote:
> > 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
> > On Fri, Oct 2, 2009 at 10:39 AM, Todd Willey <t...@rubidine.com> wrote:
> >> 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]
> >> On Fri, Oct 2, 2009 at 10:31 AM, Marak Squires <marak.squi...@gmail.com
> >> wrote:
> >> > 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
> >> > On Thu, Oct 1, 2009 at 11:07 PM, Aaron Quint <aa...@quirkey.com>
> wrote:
> >> >> 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
> >> >> On Thu, Oct 1, 2009 at 8:53 PM, Marak Squires <
> marak.squi...@gmail.com>
> >> >> wrote:
> >> >> > 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 <t...@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
> >> >> >> 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?
> >> >> >> > 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.
> >> >> >> > - 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
> >> >> >> Thanks! Looking forward to giving it a test run.
>> 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.
> 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.
>>> 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.
>>> - 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
>> Thanks! Looking forward to giving it a test run.
> Awesome! Let me/this list know how it goes or if you have questions/bug reports.
Nice! $form keeps getting added to my posts when I call
params.toHash(). Not a big deal, but not expected, either.
|
