cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gabriele Columbro" <>
Subject Re: RFC: CForms Roadmap
Date Tue, 09 Jan 2007 11:03:02 GMT
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!

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 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.4integration 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...

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.


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.

Possible Additions :


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.

> 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.


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
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?


> 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.

> regards Jeremy



Eng. Gabriele Columbro
Consultant at Sourcesense Italy
mobile: (0039)3201612846

yahoo: g.columbro
AIM:   gabrielecolumbro

"Keyboard not found.
Press F1 to continue"

View raw message