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
|