Re: RFC: CForms Roadmap
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-devw=2r=1s=css+escape+cforms+widget+idq=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
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
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
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-devw=2r=1s=css+escape+cforms+widget+idq=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
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 [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. 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
Hi Jeremy, On Sun, 2007-01-07 at 13:01 +, 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 [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: RFC: CForms Roadmap
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 -
Re: RFC: CForms Roadmap
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 +, 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 smime.p7s Description: S/MIME cryptographic signature
Re: RFC: CForms Roadmap
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
Re: RFC: CForms Roadmap
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
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 smime.p7s Description: S/MIME cryptographic signature
