[
https://issues.apache.org/jira/browse/TAP5-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718075#action_12718075
]
Fernando Racca commented on TAP5-486:
-------------------------------------
Standing from the point of view that i prefer jQuery to prototype, i would like
to see (Tapestry 5.2? ) a move into breaking down what the core web
functionalities, from those that depend on Javascript, particularly any
extensions, such as Prototype. But plain switching to jQuery is even worse.
A web framework shouldn't be tied to specific javascript/effects library such
as Prototype+Script.aculo.us
By extracting out all the components that rely heavily on dynamic javascript
behaviour into its own module, you divide and conquer. With a small layer of
abstraction on the core functionalities when needed, and on top of it, allow
people to use the javascript framework of their choice, and encourage more
people to actually add support.
I originally posted this message in the mailing list, and now i can see that
there is some consensus about moving towards an abstraction layer.
I back this comment from Kristian Marinkovi
"this unique approach would give Tapestry 5 a competitive advantage over other
web frameworks as it could support multiple javascript libraries."
> Switch Tapestry's built-in JavaScript support from Prototype to jQuery
> ----------------------------------------------------------------------
>
> Key: TAP5-486
> URL: https://issues.apache.org/jira/browse/TAP5-486
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.1.0.0
> Reporter: Howard M. Lewis Ship
>
> Like rats deserting a sinking ship ...
> This is not a definitive requirement; I've created this issue to promote
> discussion.
> It's quite likely that a move like this could be accomplished quite smoothly
> for users who are meerly consumers of JavaScript components; authors of
> JavaScript components would have to make some changes.
> Possibly we should code the jQuery stack from the get-go to NOT use the $()
> method, but instead use j$(). That extra character to type could make all the
> difference is allowing a smooth upgrade, where jQuery becomes the default,
> but prototype/scriptaculous can still be used.
> Possibly a new annotation, @PrototypeSupport for components to ensure that
> the Prototype libraries are available for compatibility?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
