cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rice Yeh" <>
Subject Re: RFC: CForms Roadmap
Date Tue, 09 Jan 2007 08:02:01 GMT
  Since namespace is employed now. Widgets' naming might start not to
include namespace-purpose prefix. For example, CFormsSuggest is better to be
just named Suggest.


On 1/7/07, Jeremy Quinn <> wrote:
> Hi All
> Now that Cocoon 2.1.11-dev runs Dojo 0.4.1, I think we have a solid
> platform to complete the modernisation of CForms client-side code.
> I hope the main outcomes of this will be :
>         Leaner: only the resources that are used will be loaded by cforms
>         Richer: more interactive widgets with wider x-platform support
>         Cleaner: eliminate most of the messy <script> tags scattered
> through
> our forms
>         Simpler: use more html templates to simplify our xslt (and simpler
> to adapt the widgets)
> Here is a list of specific goals I would love us to achieve for the
> next release.
> I hope to be working on this stuff, you would be very welcome if
> you'd like to join in !!!!
> If you would like to take on something from this list (or something I
> missed out) please discuss it on the dev list so no-one is
> duplicating effort.
> Replacements :
> Date/Time widget : replace MattKruse stuff with Dojo's implementation.
> Help & validation popups: replace MattKruse stuff with a new Dojo
> implementation.
> Tabs: replace with Dojo Tabs
> RichText: replace htmlarea with Dojo Editor, using a new fi:styling,
> so htmlarea can still be used
> MultiValue Editor: re-implement as a Dojo widget
> MultiList (OptionTransfer) Selector: replace with a new Dojo widget
> Maps: not even sure our current one is working, replace with Dojo
> (Yahoo and Google)
> Possible Additions :
> Easy graphically rich buttons, dialogs, menus etc.
> Charts to plot user data
> Colour picker
> Re-sizable textarea
> Sliders: graphical selector for number ranges etc.
> Spinner: adjust values up and down with ± buttons
> Validation: plug in client-side validation where common datatypes
> exist between CForms and Dojo, make new ones
> Issues:
> We need to do this work in such a way that has the absolute minimum
> impact on existing cforms projects.
> eg. adapting Dojo widgets to work the CForms way and not the other
> way around.
> We need to make it easier to customise the style, layout and
> behaviour of our supplied widgets.
> We are probably going to have issues with i18n and l10n.
> Dojo is only just starting to deal with this area, while CForms has
> always delt with it.
> Dojo, performs i18n on the client instead of on the server as cforms
> does.
> Very few of Dojo's widgets are i18n enabled yet.
> Dojo uses a different format of i18n message dictionary than we do
> (all of this is kind of obvious).
> Most of the work above will involve either extending existing dojo
> widgets or making new ones.
> We ought to be adding i18n/l10n as we go along.
> We need to decide whether we want to keep our message dictionary
> format (transforming it on the fly for dojo) or start using Dojo's
> format (for widget internals).
> What did I miss out ?
> I hope this whets your appetite !
> Let's get on with the replacements first !!
> WDYT ?
> regards Jeremy

View raw message