You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Jeremy Quinn <je...@fiveone.org> on 2007/01/07 14:01:37 UTC
RFC: CForms Roadmap
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
Re: RFC: CForms Roadmap
Posted by hepabolu <he...@gmail.com>.
Jeremy Quinn said the following on 9/1/07 13:12:
> 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.
I once started (way back when 2.1.7 or 2.1.8 was released) to convert
the XSLT to divs and CSS, replacing the tables. I ran into problems with
the "autoformat" settings like "columns" and "rows", because there is no
way to get that flexibly working without tables when you have no clue
what type of widget it is and how long the label is.
Also: fieldset is rendered differently in different browsers, that would
mean you have to apply CSS hacks for all possible browsers thus moving
the complication from XSLT to CSS.
Just my 2ct.
Although I'd love to tinker with this some more.
Bye, Helma
Re: RFC: CForms Roadmap
Posted by Jeremy Quinn <je...@apache.org>.
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 <je...@fiveone.org> 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
>
> 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-
AjaxForm">blah</form>
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 :
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.
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
Re: RFC: CForms Roadmap
Posted by Gabriele Columbro <co...@gmail.com>.
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 <je...@fiveone.org> 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/%3C11428584.1147087221193.JavaMail.jira@brutus%3E
-----------------------------------------
Eng. Gabriele Columbro
Consultant at Sourcesense Italy
-----------------------------------------
work: g.columbro@pronetics.it
private: columbro@gmail.com
mobile: (0039)3201612846
yahoo: g.columbro
gtalk: columbro@gmail.com
AIM: gabrielecolumbro
-----------------------------------------
"Keyboard not found.
Press F1 to continue"
-----------------------------------------
Re: RFC: CForms Roadmap
Posted by Rice Yeh <ri...@gmail.com>.
Hi,
Since namespace is employed now. Widgets' naming might start not to
include namespace-purpose prefix. For example, CFormsSuggest is better to be
just named Suggest.
Rice
On 1/7/07, Jeremy Quinn <je...@fiveone.org> 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 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
>
>
>
>
>
>
Re: RFC: CForms Roadmap
Posted by Alexander Klimetschek <al...@mindquarry.com>.
Jason Johnston schrieb:
> Can't you just escape the "."?
>
> #myform\.somefield {...}
>
> I remember CSS selectability was discussed back when the id naming rules
> were being proposed, and I thought I remembered this working correctly
> in the major browsers.
>
> Here's some thread linkage:
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&w=2&r=1&s=css+escape+cforms+widget+id&q=b
Thanks, escaping works. Would be cool to have that hint in the CForms
documentation.
Alex
--
Alexander Klimetschek
http://www.mindquarry.com
Re: RFC: CForms Roadmap
Posted by Jason Johnston <co...@lojjic.net>.
Alexander Klimetschek wrote:
> 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.
Can't you just escape the "."?
#myform\.somefield {...}
I remember CSS selectability was discussed back when the id naming rules
were being proposed, and I thought I remembered this working correctly
in the major browsers.
Here's some thread linkage:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&w=2&r=1&s=css+escape+cforms+widget+id&q=b
> 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
Re: RFC: CForms Roadmap
Posted by Alexander Klimetschek <al...@mindquarry.com>.
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
Re: RFC: CForms Roadmap
Posted by Jeremy Quinn <je...@apache.org>.
Hi Bruno
Thanks for the heads-up.
On 9 Jan 2007, at 09:06, Bruno Dumon wrote:
> Hi Jeremy,
>
> On Sun, 2007-01-07 at 13:01 +0000, 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/>
>
>>
>> Replacements :
>>
>> Date/Time widget : replace MattKruse stuff with Dojo's
>> implementation.
>
> I'm going to need this in the next couple of weeks, so it's very
> likely
> I'll work on this.
Excellent.
I hacked one up recently ..... not well enough to commit ..... one
possible issue could be problems with l10n of the dates output by the
widget. It was outputting US-style dates, I was probably doing
something wrong.
>> Help & validation popups: replace MattKruse stuff with a new Dojo
>> implementation.
>
> I've got something like this in Daisy already, it seems to work quite
> well, so I could move it into CForms.
Great !
I was thinking of using a Dialog class as this would let users turn
on cool lightbox effects etc.
>> MultiValue Editor: re-implement as a Dojo widget
>
> This is also one I'm motivated to work on, since I wrote it
> originally.
Cool again ;)
> I still need to get up-to-date with dojo 0.4 and the current
> cforms, but
> if all goes well I hope to be able to do something about these 3.
Great news!
I went through all of the implementations of the Cocoon-supplied Dojo
Widgets, trying to clean up their usage of the Widget API. So
hopefully they provide a reasonably set of clean examples for you.
Have fun ;)
regards jeremy
Re: RFC: CForms Roadmap
Posted by Bruno Dumon <br...@outerthought.org>.
Hi Jeremy,
On Sun, 2007-01-07 at 13:01 +0000, 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/>
>
> Replacements :
>
> Date/Time widget : replace MattKruse stuff with Dojo's implementation.
I'm going to need this in the next couple of weeks, so it's very likely
I'll work on this.
> Help & validation popups: replace MattKruse stuff with a new Dojo
> implementation.
I've got something like this in Daisy already, it seems to work quite
well, so I could move it into CForms.
> MultiValue Editor: re-implement as a Dojo widget
This is also one I'm motivated to work on, since I wrote it originally.
I still need to get up-to-date with dojo 0.4 and the current cforms, but
if all goes well I hope to be able to do something about these 3.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: RFC: CForms Roadmap
Posted by Carsten Ziegeler <cz...@apache.org>.
Max Pfingsthorn wrote
> By the way, has anything improved authentication-wise in Cocoon?
We have the simple CAuth framework in Cocoon which you could use for
authentication, but I think especially with Cocoon 2.2 which comes with
Spring, using Spring Acegi Security is a good choice.
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: RFC: CForms Roadmap
Posted by Max Pfingsthorn <ma...@gmail.com>.
Hi everyone,
This is very interesting! I would love to help, but I have like 5
projects going on in the university and otherwise... However, two of
them are geared at the web, so this might be interesting to investigate.
By the way, has anything improved authentication-wise in Cocoon? I
haven't quite followed the development in the last few months, but with
the real blocks and so on, it's getting more interesting for the kind of
web application I have in mind. (for which I would use struts2 otherwise
*shiver*)
Anyway, I can't commit much time right now, but I'll definitely have a
look when I get home!
Bye, and take care!
max
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 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
>
>
>