On Wed, May 2, 2012 at 10:16 AM, yazdog8 <[email protected]> wrote:
> Have you considered using http://zeptojs.com/ Zepto as your base? It's
> jQuery like, and easy to transition to full blown jQuery should you want,
> but not jQuery itself. And it's pretty light weight.
I would expect to include jQuery, but it will be configurable, and
possible to replace it with zepto. We could look at the zepto API and
try to only use things that are compatible with it.
My intentions in 5.4 is that a lot of the "optional" stuff, such as
animations, will simply be dropped; instead, there will be more DOM
events or pubsub messages to allow the developer greater control over
those visual aspects.
So, whether it is Prototype, jQuery, Zepto or any other, we primarily
need support for:
- DOM element selection & traversal
- DOM element creation / modification / removal
- DOM event listeners
- Ajax request support
Obviously, we could handle much of this using Sizzle (the CSS selector
engine) and XMLHttpRequest directly, but I'd rather leave as much of
the client stuff as possible with dedicated experts.
>
> As far as using data attributes, cracking open the JS that twitter bootstrap
> is producing has been eye opening for me, so much that most of the code my
> company is generating is based on what they're doing (listening at a body
> level for certain events triggered by DOM elements with certain data
> attributes). We now create widgets that are fired on the page just by having
> a certain data attribute (like bootstrap's data-toggle), pass URL's, pubsub
> locators, and various assorted extra information that you would normally
> have to build into a JSON object to pass over the wire.
>
Likewise; this concept ("unobtrusive JavaScript") has been around for
a while, but advances in HTML5 and jQuery have made it much more
reasonable. There's the definite advantage that putting a single event
handler function on the body tag means greater efficiency (one event
handler function, not dozens), less opportunity for memory leaks, and
much better resilience to DOM modifications, including partial page
renders.
> One thing I'd like to see is not binding pubsub to DOM elements and instead
> binding them to a global javascript object like Ben Alman does with his
> https://gist.github.com/661855 jQuery pubsub . At my place of work, we have
> the problem of DOM garbage collection in AJAX widgets. If we're dependent on
> zone updates or multiple zone updates, often we have no idea what zone is
> being fired if we're listening at a high (body) level. The pubsub events
> don't pass any reference event information along with the pubsub custom
> event, so we fly a bit blind. Instead of allowing widgets (flyouts, modals,
> etc) to be created in the body, we have to limit their creation to the zone.
> Allowing some kind of information to be passed so the listener can know that
> a specific DOM zone event was triggered (so we can initiate DOM
> cleanup/teardown) would be a very handy tool.
>
> --
> View this message in context:
> http://tapestry.1045711.n5.nabble.com/Script-Loaders-Modules-and-other-JS-thoughts-tp5676390p5681147.html
> Sent from the Tapestry - Dev mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
