> > In release X (say 5.2) we introduce a more complete Tapestry isolation > layer > and recode Tapestry's internal logic and components to use it. The > isolation layer maps to Prototype and includes parallels to the common > constructs of Prototype used by Tapestry (i.e., $(), observe(), and some > animation). When X is release, we direct 3rd party component developers to > release new versions of their libraries that code to the isolation layer.
Are you saying that the component libraries themselves should be able to switch between the supported JavaScript frameworks as well? If that's the case, there is quite a bit of wrapping-code Tapestry needs to introduce/support. Also, it'll be a lot of work for those 3rd party library authors to rewrite and test against all supported frameworks. Another problem I see is that 3rd party library authors will want to wrap existing framework-specific libraries and widgets that will always map directly to the framework they are built for. That's actually one of the main reasons for me to use jQuery: The amount of available widgets I want to work with in my Tapestry applications. I think it makes sense for built-in components to talk to the abstraction layer and of course nothing should be stopping 3rd party library creators from doing the same, since it would be very cool. But I think it is more realistic to let the 3rd party libraries dictate the JavaScript framework to include. So if you're going to use Chenillekit, you are expected to include Prototype JS into your project. And if someone creates a Tapestry-wrapper for jQuery-UI in the future, you'll have to include jQuery. The main reason to still offer some framework-specific support in Tapestry would mostly be to save precious client resources: There is no need to load up a custom plain JavaScript event-model if the application already includes Prototype or jQuery, since they already offer such a model. I also don't think our plain JavaScript code will ever be as fast as the code offered by those frameworks. My approach would be to try and keep the public interface of the Tapestry.js file largely the same so existing components using it will keep working. Then create a relatively small JavaScript object that is implemented differently for Prototype/jQuery/plain. It should only hold the absolute minimum amount of low-level functionality Tapestry depends on (like firing and listening to events, basic animation, basic selector-functionality). These Objects act as the JavaScript isolation layer and because they only offer low-level functionality the amount of maintenance required on them would be low once they are fully working. Tapestry.js should be implemented to use as much plain Javascript as possible and call into the isolation-layer where needed. So instead of using the Prototype Hash objects for example, we could be doing the same thing using either plain JavaScript arrays of by creating our own Hash-like object. regards, Onno
