cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: C2.2 dojotoolkit
Date Wed, 06 Feb 2008 20:11:26 GMT
Andy Stevens wrote:
> On 05/02/2008, Sylvain Wallez <> wrote:
>> Dev at weitling wrote:
>> Prototype/Scriptaculous has a smaller scope than Dojo that brings loads
>> of features. You don't have to use all of them though and can strip down
>> Dojo with the "compressor" they provides that embeds and obfuscates
>> everything you need in one file.
>> Prototype also considers that it "owns" the page and tweaks the
>> prototype of many built-in classes such as Object, Array, Element, etc.
>> This makes code more compact but has the very important drawback of
>> breaking other libraries you would like to use in the same page
>> (particularly the "for (prop in object)" construct no more works as
>> expected).
> Just a random thought...
> If I understand it correctly, dojo is only used by the presentation
> aspects of the forms block, and only when ajax is enabled; if ajax is
> not enabled, the forms are processed differently and don't contain any
> dojo references, just plain (X)HTML.  If so, would it be possible to
> add alternative presentation transformations that use
> prototype/scriptaculous (or jquery, or ext, or yui, or ...) instead?
> That way it could use whichever library any individual site developer
> is most comfortable with (or which is already used elsewhere in the
> site).  I guess to avoid having to add support for every available
> toolkit into the forms block itself, this part of it should be
> separated out into individual block dependencies (forms-dojo,
> forms-yui, etc.) and specifying which one to use would just be down to
> which of them you had in your app's pom and/or bean configurations.
> Or is this all a crazy dream and totally impractical?

It is theoretically possible since the server-side stuff is pretty much 
toolkit-agnostic. Now it seems maintaining one implementation is already 
a problem, so I imagine having 2 or 3 implementations won't really 
address this problem...


Sylvain Wallez -

View raw message