At the very least then we need a way to describe the "stack" used by a component and guard against incompatibilities, i.e. Protoype needed by component A and jquery by component B resulting in a conflict on the $() function.
On Sun, Jun 14, 2009 at 6:10 AM, Markus Joschko <markus.josc...@gmail.com>wrote: > I agree with Onno. There is a difference between component libraries > and the framework itself. > I want to use the framework without being forced to include some > specific javascript library. That includes > basic components like form fields etc. > I wouldn't mind if more complex components still dictate the library. > Then I can still decide whether I want to use them or not, > whether I take the hit of including two libraries in the same page etc. > However the status quo where even for the "simple things" like form > validation and basic ajax prototype is required, is very unlucky. > > Regards, > Markus > > On Sun, Jun 14, 2009 at 1:57 PM, Onno Scheffers<o...@piraya.nl> wrote: > >> > >> 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 > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- Howard M. Lewis Ship Creator of Apache Tapestry Director of Open Source Technology at Formos
