I see this as a two stage (two major release) process.
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.
Release Y (say 5.3) introduces the logic to select a JavaScript stack.
....
Another option would be a declartive one ... components would include JS but
also declare which "stack" they use, i.e.
@IncludeJavaScriptLibrary("myajaxywidget.js")
@UsesJavascriptStack("jquery")
public class MyAjaxWidget { ... }
Most components would code to the isolation layer; some might only be
functional in one "stack" or another (protoype, jquery, etc.). Tapestry
would detect stack conflicts.
I don't like this option as much.
I'm concerned that any of these approaches will hamstring component
developers, who will have to work with a very reduced JS library (the
isolation layer) in order to please users who want the option to run their
apps using one major stack or the other.
Even worse would be if components had to start including multiple versions
of their JS code to adapt to the active stack.
I think taking some time to really identify the best solution is a good
idea.
I think we'll have the time as I'm focusing on documentation for the
foreseable future.
On Sat, Jun 13, 2009 at 6:51 AM, Thiago H. de Paula Figueiredo <
thiag...@gmail.com> wrote:
> Em Sat, 13 Jun 2009 10:45:15 -0300, Onno Scheffers <o...@piraya.nl>
> escreveu:
>
> I tried that first. But the cdata node XML-encodes its content. So
>> Javascript statements like if(a < b) becomes if(a < b). It also didn't
>> seem to render out an actual CDATA block and last but not least: I wanted
>> to make sure the CDATA-line was commented out inside the script-block so
>> browsers won't trip over it.
>>
>
> Ok! :)
>
> At first I called it "Removing Prototype dependencies from Tapestry 5",
>> but the title would then wrap to the next line on most common resolutions.
>> If
>> you can come up with a better title that is no longer than what I have
>> now, I'll change it for you :o)
>>
>
> That's hard, but I'll tell you when I come up with something. :)
>
> Currently I'm reading up on the event-model. A lot of Tapestry-stuff
>> depends on the ability to fire events and respond to it. This is used for
>> things
>> like validation. It is a tricky area that is handled very differently
>> acros different browsers. Both Prototype and jQuery have both implemented
>> their
>> own custom event-model that make using your own events so easy :o)
>>
>
> This may be the trickiest part. Maybe it'll need the definition of some
> framework-indepedent API to bridge the differences between them.
>
> --
> 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
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
Director of Open Source Technology at Formos
