cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <>
Subject Re: RFC: CForms Roadmap
Date Tue, 09 Jan 2007 12:12:02 GMT

On 9 Jan 2007, at 11:03, Gabriele Columbro wrote:

> Hi Jeremy!
> First of all thx for the great job you did on the "modernization"  
> of CForms, I didn't have the proper time to investigate it or  
> better to use it (hopefully I will do that this or the next week),  
> but reading from ML threads seems to be quite cool stuff!

Thanks Gab !!

> 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.
> <snip/>
> I hope to be working on this stuff, you would be very welcome if
> you'd like to join in !!!!
> I  think I can be active on many of the improvements you mentioned,  
> but first I have to investigate a bit more, as I was saying, the  
> dojo 0.4 integration with CForms. Maybe you can pin-point me  
> ( again ;-) ) to a particular thread or some docs, or even a  
> crucial code fragment you wrote, to ease the understanding. Or  
> better I have just to dig into code...

Umm, does this help ?

> 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.
> <snip/>
> Maps: not even sure our current one is working, replace with Dojo
> (Yahoo and Google)
> I've been recently working quite hard with GMaps and Dojo, I can  
> surely help in this task, and I'm pretty motivated to work on  
> that.  Expect me coming with questions as soon as I studied your code.

I suggest you look at the existing Dojo Widgets for Google and Yahoo  
maps ;)

> Possible Additions :
> <snip/>
> Validation: plug in client-side validation where common datatypes
> exist between CForms and Dojo, make new ones
> This is also very interesting, and there's been interest in the  
> community on that in the past. I may be able to contribute also on  
> this point. But as you correctly say, let's go for the replacements  
> first.
> 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.
> +1000
> In addition to being pretty configurable in the layout, I would  
> really see CForms solve another "tedious" problem I have to face  
> while working especially in government projects with high  
> requirements of accessibility: some design is still table-based in  
> the forms styling xsl, as well as propietary attribute are  
> sometimes coming out in the html (say ajax = true, or dojoType =  
> CFormsForm, maybe the latter is changed), preventing any site to be:
> 1. completely W3C compliant

I agree, this is a problem with Dojo ATM.
Specially as this no longer works :

	<div class="dojo-SomeWidget">blah</div> or <form class="forms- 

My hope is that this is a temporary problem ;)

> 2. completely accessible (WCAG 1.0 and 2.0) and easily customizable  
> (tables are somewhere used for design purposes, and the absence of  
> div in those place limits the customization power of CSS, and  
> prevents from having a highly configurable default using this  
> [1]) .  See, I'm not looking at CForms deeply since a 2/3 months,  
> so maybe everything is already changed, but, according to me, a key  
> point in the success of CForms would to have a sensible default  
> behaviour that automagically assing CSS (multiple) classes so that  
> the forms-styling.xsl can be "almost" ignored during development,  
> and widget Id's can be used as the only, ultimate, contract between  
> developers and designers.
> WDYT? Can it be a valid improvement in this "refurbishment" roadmap?

Lots of issues here ..... not sure I have got all of them .....

Accessibility is something the Dojo team are working hard on :

ATM. most styling/layouting is done from our XSLT.
The XSLT has become really complex and scary to edit.

Widgets can supply their own instantiation templates, these are small  
files that a CForms user could override.

So instead of the xslt outputting the whole structure, onclick  
scripts and all the current complication, it should be able to output  
something much simpler eg.

	<input name="startdate" dojoType="forms:CFormsDateWidget"/>

Users not using Dojo or JavaScript would just get a normal date field.
Users with Dojo, the forms:CFormsDateWidget would replace that tag  
with it's instantiation template, via DOM manipulation.

So my point here is that this should begin to simplify the cforms xslt.

The next level of complexity, is all of the groups and layout stuff  
in the cforms xslt.
In hindsight, it seems this could have been done cleaner in a  
separate namespace, but we do not have that option now, unless we  
want to force everyone to completely re-work their form templates etc.

However, I do find lots of inconsistencies with the layouting  
code ..... for instance, I have not found a way to combine the  
layouting tags with stuff like repeaters and as you say, there is  
possibly too much usage of tables.

I would love to see more of the layout structure use divs and css,  
but this was not done originally I suspect as these types of layouts  
are more difficult to achieve.

So as the xslt gets simplified, we can hopefully see more clearly how  
to produce cleaner markup from the layouting tags ?

(Sorry, I am not sure I have answered all of your issues ;))

> <snip/>
> I hope this whets your appetite !
> Sure it does ;-)
> Let's get on with the replacements first !!
> Yep, hopefully I can come again with more appropriate questions of  
> proposals in a 10 days time.

Many thanks for your feedback !

regards Jeremy

View raw message