cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <jer...@apache.org>
Subject RFC: CForms + Dojo: the way forward
Date Fri, 06 Oct 2006 14:42:31 GMT
Hi All

We had an informal group discussion on Tuesday at the Hackathon about  
CForms.
The purpose of the discussion was to find a consensus on the  
direction to take CForms, so that everybody who would like to work on  
it is hopefully going to take it in the same general direction.

These are some of the points that were raised and some of the  
tentative conclusions we reached.

1. Too much javascript gets loaded unconditionally when a cform is used.

Conclusion: we should rely as much as possible on dojo lazy-loading,  
but we could also take a parallel approach of an extra transformation  
step on templates in xslt to discover which libraries are actually  
being used, then only add those script tags.


2. Dojo's lazy-loading capabilities are not being taken full  
advantage of. (this follows on from above)

Conclusion: ideally a cforms page should only have script tags to  
load the dojo and cocoon-forms bootstrap, all other loading should  
come from the use of dojo.require if possible. The dojo.require  
statements can either be in the Widget code or in script tags in the  
CForms Widgets, but not put unconditionally into the head/script.


3. We have two templating systems, there are incompatibilities  
between them and different capabilities, can we deprecate one?

Conclusion: the JXMacro generation technique seems to be more popular  
and capable. We should if possible deprecate the use of the  
FormsTransformer, adding any missing functionality to the JXMacro  
lib. Before we decide this, we need an accurate idea of all  
compatibility and any performance differences between the two. We  
need to write some docs explaining the migration path.


4. Can we replace some of the legacy libs with similar functionality  
in Dojo?

Conclusion: Everyone seemed happy to replace legacy javascript libs  
with their equivalent in Dojo. However, it should be done in a way to  
allow the usage of eg. HtmlArea editor as it could have capabilities  
that certain projects need that are not offered by Dojo rich text  
editor. Some legacy libs do not have equivalent Dojo implementations,  
these need to be written as Cocoon namespaced Dojo Widgets and/or  
could be contributed to Dojo.


5. It would be worth upgrading our current custom Dojo widgets to the  
latest widget APIs, this will make it easier to upgrade to the next  
version of Dojo when it is released.

Conclusion: where possible, existing Cocoon namespaced Dojo widgets  
should be adjusted to use the newer API : dojo.widget.defineWidget


6. Dojo has an ant build script which uses Rhino to compile and  
compress all needed dojo code into a single file. This speeds up the  
client *significantly*. How can we use this better from within Cocoon?

Conclusion: It would be of great advantage to have this dojo  
compressor build, better integrated into Cocoon, so that an optimised  
production environment can be used. The compressor does 2 things:  
aggregate and compress all of the required dojo packages, aggregate  
all of the html template and css snippets required by the widgets you  
actually need. This functionality is already in place (src/blocks/ 
ajax/dojo/), it is just not obvious or automatable. Currently you  
would create a listing of the required dojo libs by hand, then run  
the build script. Can and should we find a way to automate this?


7. Fallback in the case of no javascript

Conclusion: wherever possible, our Dojo Widgets should be designed to  
place simple workable fields in forms, that get embellished if Dojo  
is available, so if Javascript is turned off, at least some  
functionality is available. This is normal dojo practise i.e.  
<textarea class="dojo-Editor" name="editorContent">some content</ 
textarea> : you get a normal textarea if dojo is not available, but a  
wysiwyg editor if it is.

I think we have and need to retain these 3 usecases :
	javascript is available + developer wants Ajax behaviours
	javascript is available + developer does not want Ajax behaviours
	javascript is not available



Before each or any of the changes above are made, it will obviously  
need a fuller discussion about the details of each change.

Your feedback and efforts at implementing these changes would be  
gratefully accepted.


regards Jeremy


Mime
View raw message