I've always had a love/hate relationship with JavaScript; some of the earliest motivations for Tapestry was to "encapsulate that ugly JavaScript stuff so I don't have to worry about it again." However, as I've come to appreciate JavaScript, over time, as a powerful functional language, and not as an incompletely implemented object oriented language, my revulsion for the language has disappeared ... even reversed.
Back around 2006, I started adding the client-side JavaScript features to Tapestry 5; this started with client-side form field validation, and grew to include a number of more sophisticated components. The good news is these features and components are fully encapsulated: they can be used freely throughout at Tapestry application without even knowing JavaScript. Tapestry includes the libraries (and related CSS documents) as needed, and encapsulates the necessary initialization JavaScript. The APIs for this were revamped a bit in Tapestry 5.2, but the core concept is unchanged.
The bad news is that the client-side is directly linked to Prototype and Scriptaculous (which are bundled right inside the Tapestry JAR file). These were great choices back in 2006, when jQuery was new and undocumented (or so my quite fallible memory serves). It seemed safe to follow Rails. Now, of course, jQuery rules the world. I've been talking for a couple of years about introducing an abstraction layer to break down the Prototype/Scriptaculous dependency; meanwhile I've recently seen that Rails and Grails are themselves moving to jQuery.
However, that abstraction layer is still important; I have clients that like MooTools; I have clients that are using YUI and ExtJS.
Certainly, it would have been too ambitious to try to start with such an abstraction layer from day 1. At the time, I had no real idea what the relationship between JavaScript on the client, and the application running on the server, would look like. Also, my JavaScript skills in 2006 are a fraction of what they are now. With several years of coding complex JavaScript and Ajax components for Tapestry, for TapX, and for clients, I think I have a much better understanding of what the APIs and abstraction layers should look like.
So suddenly, I have a number of goals:
- Allow Tapestry to work on top any JavaScript framework
- Support Prototype/Scriptaculous and jQuery as substrate frameworks "out of the box"
- Make the built-in Tapestry library first class: documented and release-on-release compatible
- Keep backwards compatibility to Tapestry 5.2
What I'm proposing is a gradual transition, over Tapestry 5.3 and 5.4, where new, documented, stable JavaScript APIs are introduced. and Tapestry and 3rd party libraries can code to the new APIs rather than to Prototype/Scriptaculous. The goal is that, eventually, it will be possible to switch the default substrate from Prototype/Scriptaculous over to jQuery.
7 comments:
Excellent direction for Tapestry JS! Can't wait!
That sound's good!!
I think that's what Kris Marinkovic tried to explain in the Tracking issue for Ajax support: https://issues.apache.org/jira/browse/TAPESTRY-1650
Hi Howard,
Why do you never talk about Dojo JS framework. If you want name spacing, joint development, components. You should really give it try. I love Jquery, but it's most useful for fancy small projects with a slideshow, a popup, few animations etc.
Building a complete js ui with jquery is a pain !!!
Give a try to dojo, you should love it: consistent, documented, clear, automatic dependency resolution, java like import etc....
Anyway the best would be to have something like tap 4.2 with a Tapestry JS interface library (a set of empty functions), then we should implement the interface for JQUERY or MooTools or Dojo...
This interface should handle the following basic bits:
- record validation constraints,
- record form errors
- ajax requests
- node replacement etc...
Cheers,
Numa
@Numito,
Tapestry used Dojo in the past, I don't remember exactly which version, but was a long time ago...
Finally! This step is long overdue.
I'd prefer YUI though, as jQuery just hasnt got the level of documentation and the consistent set widgets.
IBM has decided that DOJO is their preferred library and not only that any other JS libraries should not be used at all on any IBM site.
We picked T4 library comparing to other available framework several years back and since it supported dojo we picked T4.
Now we have to migrate to T5 and we definitely need dojo support for that.
@Jayesh
Well, I'm glad you've had success with T4, but that's code that's 5+ years old. All the focus has shifted to T5.
I cringe anytime I hear a blanket architectural decision coming from "the grey beards". These are never productive, usually just the opposite. But that's a discussion for another time.
Meanwhile, 5.4 is finally getting the JavaScript abstraction layer I've been hoping to implement for quite some time. Although I'm not familiar with Dojo, I suspect Dojo integration will not be very difficult.
Post a Comment