cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Klimetschek <alexander.klimetsc...@mindquarry.com>
Subject Re: RFC: CForms Roadmap
Date Wed, 10 Jan 2007 19:21:24 GMT
Hi Jeremy, hi all,

I have another feature request for Cforms: change the widget hierarchy 
separator from "." to something else ("_"), eg. having a form called 
"myform" containing a widget named "somefield" would result in the fully 
qualified widget id "myform_somefield".

The problem is that having a dot in the ids makes it very hard to do CSS 
styling for the final HTML version of the form. This is because CSS id 
selectors cannot contain a ".", that is reserved for class selectors. 
For example:

#myform.somefield {
   // styling...
}

is incorrect CSS or at least is interpreted as

#myform .somefield {
   // styling..
}

aka "element with id myform and below any element with the class somefield".

A way to work around is either to define your special classes via 
fi:styling or to write complicated selectors that take the structure of 
the HTML document into account (div.someclass div.foobar input.forms 
...). Both are very limited: fi:styling is difficult if you are using 
custom styled elements (=custom XSL) where you cannot easily set a class 
and it does not work if you want to use it together with the standard 
classes like "active" or "output". And it requires the CSS designer to 
change the form templates probably on each modification, which IMHO 
violates separation of concerns. The other solution I don't wanna talk 
about... ;-)

Jeremy you said that the dot separator is basic assumption for all the 
cforms java code, so that it would be a massive change. Nevertheless I 
find it quite a major flaw in the cforms design (the only one I know of ;-).

WDYT?

Alex

Jeremy Quinn schrieb:
> 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
> 
> 
> 


-- 
Alexander Klimetschek
http://www.mindquarry.com


Mime
View raw message