Em Sun, 14 Jun 2009 08:57:03 -0300, Onno Scheffers <o...@piraya.nl> escreveu:

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.

I think so. That's something that was already warned in this thread.

Also, it'll be a lot of work for those 3rd party library authors to rewrite and test against all supported frameworks.

I don't think Howard meant this. A core library has a way larger demand for being framework-agnostic than a 3rd party one.

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.

In this case, the author can use the Tapestry Javascript abstraction layer or use the no-conflict way of the JS framework. For example, as Onno pointed out, the jQuery guidelines state that plugins should use jQuery() instead of $(), preventing conflicts.

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.

I guess that's exatcly what Howard said about the Javascript stack idea.

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.

I agree 100%. It would be the encapsulation of the abstraction layer in a single Javascript object. Simple and elegant. ;)

--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Reply via email to