[jira] Commented: (TAP5-486) Switch Tapestry's built-in JavaScript support from Prototype to jQuery
[ https://issues.apache.org/jira/browse/TAP5-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12889836#action_12889836 ] fritz commented on TAP5-486: There's no rationale for having Java developers dictating what Javascript framework front end developers should be using. Surely the way forward is to decouple the two to allow developers to plug in ANY framework they want into Tapestry. Prototype is not the best framework out there. I suspect Java developers only picked Prototype because it uses the word 'Class' which give them a warm fuzzy feeling. 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.
[jira] Commented: (TAP5-486) Switch Tapestry's built-in JavaScript support from Prototype to jQuery
[ https://issues.apache.org/jira/browse/TAP5-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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: 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.
[jira] Commented: (TAP5-486) Switch Tapestry's built-in JavaScript support from Prototype to jQuery
[ https://issues.apache.org/jira/browse/TAP5-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12708861#action_12708861 ] Adrian commented on TAP5-486: - +1 for a thin wrapper/interface approach allowing different javascript frameworks to be plugged in. jQuery is my preferred library but don't agree in forcing people to switch from Prototype. Need to also stop Prototype taking ownership of the $ symbol, I shouldn't really have to write $j or j$ everywhere. 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.
[jira] Commented: (TAP5-486) Switch Tapestry's built-in JavaScript support from Prototype to jQuery
[ https://issues.apache.org/jira/browse/TAP5-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12674864#action_12674864 ] luna Guo commented on TAP5-486: --- jQuery has thousands of plugins that i can use them easily without much javascript experience.I can't leave it .Even i've written some code using prototype,i have to include jQuery for using a lot of UI components.There's hundreds kb of javascript for a page. I think the javascript lib tapestry include must be small and a lot of UI can be find.I like jQuery's Write Less, Do More. To use a small one,and never change it to another again.We don't want to lean/use so many javascript frameworks. 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.
[jira] Commented: (TAP5-486) Switch Tapestry's built-in JavaScript support from Prototype to jQuery
[ https://issues.apache.org/jira/browse/TAP5-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12669197#action_12669197 ] Joost Schouten commented on TAP5-486: - A switch would mean a lot of work on a few project for me too. So a switch would not get my vote. One thing that I would find interesting is to change the tapestry.js, and some of the other included *.js files into an thin interface like wrapper that does not rely on any framework. Then pull out all javascript into a seperate module and contribute the javascript module of your choice. This way nothing needs to change from the way it currently works with prototype (assuming prototype as the default), but it does allow to plug in any other framework, like jQuery or MooTools. Martin Reurings actually proposed a similair solution back in 2007 http://mail-archives.apache.org/mod_mbox/tapestry-dev/200710.mbox/%3cof6624565c.dad9ba14-onc1257369.00426459-c1257369.00440...@porsche.co.at%3e Cheers, Joost 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.
[jira] Commented: (TAP5-486) Switch Tapestry's built-in JavaScript support from Prototype to jQuery
[ https://issues.apache.org/jira/browse/TAP5-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668931#action_12668931 ] Robert Zeigler commented on TAP5-486: - I'm with Dan. This is a major change. The @PrototypeSupport is a nice idea, except that it requires more than minor amounts of work for authors of complex applications; backwards compatibility, to me, means that if I absolutely have to make changes, those changes should take less than 30 minutes for a single developer to make for a complex app. For example, I recently upgraded a dependency in a complex application from cayenne 2.0.4 to cayenne 3.0M5. Although the change resulted in various deprecated warnings, the application still functioned correctly without any further changes on my part, meaning that I could fix the warnings at my leisure. So if we were going to change the default js library, the change /has/ to be done in such a way as to make the burden of the change shouldered by tapestry, and not the end-developer. I think @PrototypeSupport is an /interesting/ idea, but it's one that requires too high an activation energy: too much effort. If you're going to make the change, then I think that you should spend time developing a tapestry js api into which various framework can be plugged. This idea has been proposed before; I never much cared for it; more cruft on top of cruft. But if you want to switch the default js library to jquery, then this is the way to go. That way, previously written applications can override the default library contributions and contribute prototype, instead. There could even be a small t5prototype library that does this contributing for you, so all you have to do as a user to maintain the previous behavior is include the extra dependency. That's my $0.02. 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.
[jira] Commented: (TAP5-486) Switch Tapestry's built-in JavaScript support from Prototype to jQuery
[ https://issues.apache.org/jira/browse/TAP5-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668932#action_12668932 ] Martin Strand commented on TAP5-486: I would love to see jQuery instead of Prototype, we use jQuery for our .NET apps so we have a lot of jQuery code already. Not that it's difficult to port code between the two, but it would be nice to reuse the exact same components without having to load two rather large js libraries on a T5 page. It also feels like jQuery is more widely used, with a huge number of plugins available. However, as Dan points out, such a switch could break the promise of backwards compatibility. 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.
[jira] Commented: (TAP5-486) Switch Tapestry's built-in JavaScript support from Prototype to jQuery
[ https://issues.apache.org/jira/browse/TAP5-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12669057#action_12669057 ] Igor Drobiazko commented on TAP5-486: - I think the switch from Prototype to jQuery is the worst thing we can do for Tapestry now. I have spoken to a lot of people who are raising concerns about Tapestry's back compatibility. Usually this is the only reason not to use Tapestry. Tapestry has to restore the developers' confidence. Some time ago a decision (for using Prototype) was made, now we have to live with it. 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.
