cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simone Gianni (JIRA)" <>
Subject [jira] Updated: (COCOON-1782) [PATCH] Support for CSS classes in cocoon forms XSL
Date Thu, 30 Mar 2006 16:02:26 GMT
     [ ]

Simone Gianni updated COCOON-1782:

    Attachment: xsl-css-2.diff

Adjusted the patch to work with recent changes in XSLs.

Also fixed an annoying bug in IE : since Ie does not trigger an onchange event when the user
clicks on a radio button or on a checkbox, the onchange (and the ajax update) will happen
only when the user then clicks on something else (simultaneous to the onblur event). So I've
changed the XSL so that when a radio button or a checkbox is used the onclick event is used
instead of the onchange. This could lead to a few more form submits than those strictly needed,
but will update the page at the right time and not wait for the user to click away from a
radio or checkbox.

> [PATCH] Support for CSS classes in cocoon forms XSL
> ---------------------------------------------------
>          Key: COCOON-1782
>          URL:
>      Project: Cocoon
>         Type: Improvement
>   Components: Blocks: Forms
>     Reporter: Simone Gianni
>  Attachments: xsl-css-2.diff, xsl-css-trunk.diff, xsl-css.diff
> Added CSS classes to key elements in default cocoon forms XSL. Here is a brief explanation
of how it works :
> -----------------------
> 	Common fields styling
> The general rule for common fields (styled by forms-field-styling.xsl) is to apply the
following classes :
> - "forms" : is placed always, to avoid name clashes with already present site-specific
> - <widget name> : can be "field", "action", "output", "booleanfield", "multivaluefield",
"upload", "repeater", "imagemap", "aggregatefield", "form", "messages".
> - <state> : the state of the widget, can be empty, "active", "disbled", "output".
> - "required" : if the widget is required.
> - "with-errors" : if there are some fi:validation-messages associated with the widget.
> - <class> : an optional, user defined, fi:styling/@class that can be specified
on a field to fine tune widget styling.
> This technique makes it easy to write very specific CSS rules, as much as very general
ones. For example :
> input.required {
> 	color: blue;
> }
> Will make all required inputs have a blue text color, while
> input.upload.required {
> 	color: red;
> }
> will make only the required upload widgets have a red text color.
> The HTML elements to which this classes will be applied varies depending on the widget
type and special fi:styling attributes (like list-type for selection lists, fi:styling/@type
> There are also other classes, placed to correctly style other elements, these are :
> - "captcha" : applied to the img element of a captcha field.
> - "required-mark" : applied to the span containing the "*" near the required fields.
> - "validation-message" : applied to the anchor element containing the "!" near the fields
with errors.
> - "vertical-list" and "horizontal-list" : applied to the tables used to layout these
kind of lists.
> - "upload-change-button" : applied to the button that appears next to the upload widget
when a file has been uploaded.
> For the validation-errors element (which outputs a list of all validation errors found
in the form) there are other special classes : 
> - "validation-errors" : applied to the div that contains the errors recap block.
> - "validation-errors-header" and "validation-errors-footer" : applied to the paragraphs
that contains the header and footer of the errors recap.
> - "validation-errors-content" : applied to the "li" element of the errors list.
> 	Page styling
> Another set of classes is used for page styling (forms-page-styling.xsl). The general
rule for fi:group is to apply the following classes :
> - "forms" : as always placed to mark a cocoon forms CSS class.
> - "group" : identify a group class
> - <layout> or <type> : the fi:styling/@layout or fi:styling/@type of the
> - <class> : an optional, user defined, fi:styling/@class that can be specified
on a group to fine tune styling.
> As for the widgets, these classes are applied to different HTML elements depèending
on the group type and layout.
> For those layouts which uses tables, special classes are used to mark specific cells
> - "label" : applied to the "td" containing the label
> - "content" : applied to the "td" containing the form input
> - "action" : applied to the "td" containing an action widget, for those layouts that
creates special cells for this widgets.
> - "booleanfield" : applied to the "td" containing a booleanfield widget, for those layouts
that creates special cells for this widgets.
> - "other" : applied to the "td" containing other content, like another nested fi:group
or non cocoon forms elements.
> Consider this CSS snippet :
> {
> 	border: 1px solid blue;
> }
> td {
> 	background: yellow;
> }
> td.label {
> 	background: blue;
> 	color: white;
> 	width: 20%;
> }
> This will style every fi:group with layout "columns" placing a blue border on the table,
then using a yello background for every cell in the table, while a blue blackground, a while
text color and a width of 20% will be used for cells containing labels.
> A special case of layout is handled directly in the basic xsl (forms-field-styling.xsl),
which format with a "columns" similar layout a "fi:form". In this case the same classes (label,
content etc..) applies.
> Some special classes are used for the tab layout. These are :
> - "tabArea" : applied to the div containing the tabs.
> - "tabContent" : applied to the div containing the tabs contents.
> - "tab" : applied to every span representing a single tab
> - "active" : marks the currently active tab.
> - "validation-message" : applied to the span placed in a tab when there are validation-messages
in any control inside that tab.
> 	Compatibility with old classes
> The cocoon forms XSLs prior to this patch used a few CSS classes for tabs, required marks,
validation messages and another few elements. These classes have been mantained to grant backward
compatibilty, but should not be used anymore.
> -----------------------
> Thanks to Derek Hohls and Helma for sharing with me their work on this subject.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message