tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fernando Racca (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (TAP5-486) Switch Tapestry's built-in JavaScript support from Prototype to jQuery
Date Wed, 10 Jun 2009 13:26:07 GMT

    [ 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.


Mime
View raw message