[jira] Issue Comment Edited: (TAP5-486) Switch Tapestry's built-in JavaScript support from Prototype to jQuery

["Fernando Racca (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TAP5-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718075#action_12718075 ] 

Fernando Racca edited comment on TAP5-486 at 6/10/09 6:24 AM:
--------------------------------------------------------------

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 Marinkovic 

"this unique approach would give Tapestry 5 a competitive advantage over other web frameworks as it could support multiple javascript libraries."


      was (Author: fracca):
    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.