Even more of a reason to encapsulate as much as possible all this patches.
Otherwise, as time passes, the API would end up polluted with javascript
patches to support required behaviour.
In my view, javascript/css is a very dangerous arena, and deep integration
can lead you to lock-ins such as this one.
IMHO, tapestry-core should be as javascript free as possible, and another
module should start to model, in the best possible way, how to deal with the
UI.
I believe it's mentioned in the comments of the previously-referenced
jira, but, the main reason this issue is trickier than it seems is
that there are many applications in existence already that are relying
on:
1) The fact that tapestry bundles prototype
2) The fact that tapestry relies on prototype.
A trivial example: T5 defines a set of effects (based on the prototype/
scriptaculous effects) for animating the introduction of content.
These are reasonable, but there are cases where they aren't quite
right (such as a slide transition that is too fast or too slow).
Currently, the only way to work around that is to "monkey-patch"
tapestry's effect object. But you're now relying on explicit
knowledge that tapestry is using prototype. Any and every such
instance would be broken if we were to rewrite tapestry javascript
handling to use:
a) a different framework
b) no framework
c) an abstracted API with framework-specific implementations.
--
View this message in context:
http://n2.nabble.com/Switch-from-Prototype-to-jQuery--tp2245624p3057621.html
Sent from the Tapestry Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
