I've been doing a lot of work using Prototype for the Ajax support in Tapestry 5. I use Prototype because it is generally easy to use, easy to bundle with Tapestry and reasonably well documented.
I've been gradually using new features as I need them and as I grow more comfortable with Prototype. I just started using some custom events (related to synchronizing some data when a form is submitted).
Here's an important note: custom events, used with the fire() function must contain a colon. this.form.fire("prepareforsubmit") will do nothing. this.form.fire("form:prepareforsubmit") will properly invoke observers. This is not yet documented, though the ironically named blog Painfully Obvious clued me in.
You should consider using The Yahoo! User Interface Library (YUI) (http://developer.yahoo.com/yui/). The functions and features are excellent as well as the documentation. And the javascript libraries are well geo-located (and cached) around the globe on Yahoo!s servers.
ReplyDeleteI second that. Prototype pollutes the browser's namespace and disregards most lessons learned in modern JavaScript programming (don't touch built-in prototypes, put all your stuff in a namespace, make your library modular rather than a monolithic chunk).
ReplyDeleteYUI is much better documented than Prototype or Dojo and historically has had better cross-browser event handling, excellent dependency management and CSS selectors that are close to jQuery's elegance. Unlike jQuery YUI doesn't have a thousand widgets to choose from, but what's there has been tested by millions of YAHOO users and not thousands of Ruby developers.
If you're searching for an Ajax-library to include out-of-the-box in Tapestry 5, Prototype IMHO shouldn't be it.
I'm also not too happy with the T5 prototype decision. T5 is such a smart general purpose web framework and it should not be tied that close with prototype.
ReplyDeletePrototype indeed does pollute the dom and the fact that there's no namespace makes interoperability with other libs hairy.
IMHO Tapestry 5 deserves a js lib which is more elegant (like jquery is), modular, and interoperable.
I have used YUI in the past, and it is good for UI stuff. They have lots of widgets and nice documentation. But, I found it pretty heavy, and hard to use at times. For simple tasks (and some UI) I started using jQuery and I haven't looked back. I would love to see jQuery support built into T5, but if it isn't, no big deal.
ReplyDeleteThanks for your feedback; we've updated the Prototype docs to reflect this.
ReplyDeleteTo address the other comments: Prototype is bundled with Ruby on Rails, is used on many popular sites, and somehow the sky doesn't fall down. We understand the concerns about extending built-ins, but we choose to address real-life, practical conflicts, rather than theoretical conflicts.
Why don't you create a adapter layer like Ext xxx-adapter? So developers can use their desired library. Take a look at this - http://extjs.com/learn/Ext_FAQ#What_is_the_proper_include_order_for_my_JavaScript_files.3F
ReplyDeleteMaybe you should adopt an adapter architecture like Shadowbox that allows different frameworks to be used.
ReplyDeleteThere's been discussion and issues on the mailing lists (where further discussion belongs) as to an insulating layer that would allow dev's thier choice (Prototype, JQuery, YUI, etc.).
ReplyDeleteI actually started a switch from Proto/Scriptacluous to JQuery but it didn't work out for me.
My JavaScript Mojo is much weaker than my Java Mojo. I don't like working in JavaScript. Certainly, I need to work out exactly what Tapestry 5's client-side needs are before I can work out what a pluggable generic layer would look like.
When I hear T5 users complain about prototype, especially T4/dojo users, there's only one complaint that doesn't cause me to giggle, and that's the concern about screwing around with the prototypes of internal objects. Java developers are addicted to long object names and boiler plate code, so when something comes along that treats all of the 'problems' that boiler plate code was supposed to solve as a non-issue, panties get wadded.
ReplyDeletePersonally I've never run into a project where Prototype tinkerings caused any damage, and I've always been glad that I can write readable, terse, cross-browser code quickly. It is however a legitimate concern which has been demonstrated. I also feel that T5 is in a different position than say RoR, and ignoring the concern as RoR has done won't be as easy. Not to say that RoR can't be/isn't used for corporate environments, but java has a deep entrenchment on this plane and therefore a generally different audience - an audience that stereotypically isn't as agile.
I'm sorry, but the "RoR and Prototype run on many websites and therefor the problems you have with them are non-existent" is a very stupid argument. A problem, btw, is by definition theoretical until it brings your project down.
ReplyDeleteThat said, the RoR-fanboys have always tried to discuss problems away by saying its a non-issue: like Server scaling, thread synchronisation, Unicode support. Never owning up to your hyped products problems doesn't make them go away.
Finally: Prototype's problems RESTRICT the developers' choices. They're not "theoretical problems", they're adoption barriers.
Integrating Tapestry with a library that doesn't have Prototype's problems, like jQuery or YUI, will enable the developers to use Tapestry's widgets ALONG with Prototype's. Integrating Prototype will prevent future Tapestry developers from choosing other libraries.
It's that simple.
"My JavaScript Mojo is much weaker than my Java Mojo. I don't like working in JavaScript. Certainly, I need to work out exactly what Tapestry 5's client-side needs are"
ReplyDeleteThere are some Tapestry adherents out there who have awesome JavaScript Mojo. Perhaps they could volunteer/be brought on as committers? Just MHO.
I agree with Bill Holloway... leave the Javascript decisions to the Javascript experts.
ReplyDelete