I'd just like to echo everything Robert said in this message. > -----Original Message----- > From: robert zeigler [mailto:robert.zeig...@gmail.com] On Behalf Of > Robert Zeigler > Sent: 10 June 2009 18:54 > To: Tapestry users > Subject: Re: Switch from Prototype to jQuery? > > I believe it's mentioned in the comments of the previously-referenced > jira, but, the main reason this issue is trickier than it seems is > that there are many applications in existence already that are relying > on: > 1) The fact that tapestry bundles prototype > 2) The fact that tapestry relies on prototype. > > A trivial example: T5 defines a set of effects (based on the prototype/ > scriptaculous effects) for animating the introduction of content. > These are reasonable, but there are cases where they aren't quite > right (such as a slide transition that is too fast or too slow). > Currently, the only way to work around that is to "monkey-patch" > tapestry's effect object. But you're now relying on explicit > knowledge that tapestry is using prototype. Any and every such > instance would be broken if we were to rewrite tapestry javascript > handling to use: > a) a different framework > b) no framework > c) an abstracted API with framework-specific implementations. > > Prototype may have been the "wrong choice" (something which is more > opinion than fact), but switching js approaches in the middle of the > game is definitely an idea that needs to be approached with copious > amounts of caution and consideration. > > Robert > > On Jun 10, 2009, at 6/1010:49 AM , Onno Scheffers wrote: > > >> > >> Maybe it doesn't have to be plain js since there's a lot to be > >> gained from > >> these libraries. Perhaps all Tapestry's .js files could be moved to > a > >> tapestry-prototype module, each of those files could then be > >> reimplemented > >> in a tapestry-jquery module. > >> A problem remains with script snippets written directly from > >> renderSupport.addScript() > >> It sounds pretty cumbersome to maintain multiple modules though. > > > > > > > > The main reason for the plain-Javascript solution is indeed that you > > will > > need to support the Javascript files for each and every framework > > you're > > going to support in the future. This will make writing new > > components quite > > a lot of work as well because you will need to write/update the code > > for all > > supported libraries. > > By sticking to plain Javascript, you don't have that problem. > > > > regards, > > > > Onno > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org >
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
