Wow, this is exactly the kind of interface I dislike. It's way too verbose and I'm not sure why one would add this kind of layer on top of jQuery. I don't see where it makes things easier - it's more like it just provides yet another interface.
Simplistic means treating complex issues and problems as if they were much simpler, that's exactly what Jquery and its suit of plugins (including Amplify) does well.
So 'simplistic' is right? Would 'simplified' be incorrect here?
EDIT: A spot of googling shows that 'simple' is generally held to be the correct word in this context. I guess 'simplified' implies they've taken something complicated and made it simpler, whilst 'simple' implies they've not made anything more complicated than it needs to be.
1. I don't like magic string names like "AjaxExample1". Why not return an object, and use:
var AjaxExpample1 = amplify.request...
2. It is not clear how you mix get parameters and post data. If I want to POST to "/users/{id}/", how do I separate the post values from the parameter?
is mixing concerns (network protocol, caching, serialization, model) that you probably don't want to mix that way in a real app.
It's pretty trivial to roll the polling part yourself (setTimeout), if you really need a plugin then PeriodicalUpdater[1] might be a candidate (although there are many others, and the cool kids use comet/websocket now anyways).
I didn't quite understand the purpose of the caching part; the browser already caches for us after all. It seems like a misnomer for some sort of bridge to the localstorage, but I didn't quite get in what situation storing the verbatim server response would be useful - as opposed to storing the deserialized result (or part thereof).
Anyways for the serialization part JSON2.js[2] is your friend.
And for models there are various choices, backbone.js[3] being the most popular recently.
-- The 'store' module --
doesn't seem to provide anything interesting over jq-store[4]. And if you really want your data to stick around then there's evercookie[5]
-- The 'pubsub' module --
was a little hard for me to understand the purpose of.
Since it isn't actually about server messaging(?) but rather only a way of passing events inside the browser it seems like what you'd really want is either JavascriptMVC[6], Backbone[3], perhaps knockout[7], or the older chain.js[8], or maybe one of the other two dozen data binding plugins.
Admittedly on this last one I may very well just be missing the point entirely. PubSub inside the browser? Huh?
Would love to see someone explain what this library does in simpler terms. I can't tell which terms are buzzwords, which are industry standard, and which terms are from their own internal vocabulary. PubSub? PubSub to what? Can you give some real world examples of when to use this library and what problems it solves.
There's a typo in the first example. You're missing a '1' in the first argument when you execute the ajax call.
The pub/sub is all local right? I got really excited, then not so much. I still see the value, but I was hoping it was more like Google's javascript+serverside-component PuSH client. [1]
(It's really cool, Google runs a PuSH bridge so their server side component subscribes to a Pubsubhubbub hub and receives updates and pushes them to the browser. I want to see an OSS implementation of it since it's really slick and PuSH is a neat protocol).
