Re: RFC: CForms Roadmap

[Jeremy Quinn]

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 <[EMAIL PROTECTED]> 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 ?

        http://www.mail-archive.com/dev@cocoon.apache.org/msg48987.html

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




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



1. completely W3C compliant

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

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



My hope is that this is a temporary problem ;)

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

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 :

        http://manual.dojotoolkit.org/WikiHome/DojoDotBook/Book90

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





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

Users not using Dojo or JavaScript would just get a normal date field.


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









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

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. Users with Dojo, the forms:CFormsDateWidget would replace that tag with it's instantiation template, via DOM manipulation. 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 ?

<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

smime.p7s
Description: S/MIME cryptographic signature