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 <[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.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.
<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. 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 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? <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.
regards Jeremy
Ciao, Gab [1] http://mail-archives.apache.org/mod_mbox/cocoon-dev/200605.mbox/[EMAIL PROTECTED] ----------------------------------------- Eng. Gabriele Columbro Consultant at Sourcesense Italy ----------------------------------------- work: [EMAIL PROTECTED] private: [EMAIL PROTECTED] mobile: (0039)3201612846 yahoo: g.columbro gtalk: [EMAIL PROTECTED] AIM: gabrielecolumbro ----------------------------------------- "Keyboard not found. Press F1 to continue" -----------------------------------------
