tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michal Buczko (JIRA)" <j...@apache.org>
Subject [jira] Commented: (TAP5-486) Switch Tapestry's built-in JavaScript support from Prototype to jQuery
Date Mon, 15 Jun 2009 18:06:07 GMT

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

Michal Buczko commented on TAP5-486:

The only thing that tapestry needs is stabilization. I'm developing my own application over
1 year in tapestry 5 with extensive use of javascript and it  drives me really mad to re-implement
 parts of my javascripts each time when tapestry updates from 5.1.0.x to 5.1.0.x+1. And now
I hear about  switching from prototype to jquery!

please decide here what the tapestry 5 is:  stable framework for wide community or a never-ending-beta-toy
for few developers. Even hardcore developer's patience has its limits. Changing the same thing
100 times because of minor updates starts to be irritating.

There are lot of issues reported which are imho much more important than wasting time on swtiching
from one js library to another. I would love to see tapestry described as a superb fast &
stable tool, but let's be honest: who will use this framework for serious job if it changes
constantly each month and number of jira tickets rises exponentially?

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

View raw message