You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "Simone Gianni (JIRA)" <ji...@apache.org> on 2006/02/20 16:36:25 UTC
[jira] Created: (COCOON-1782) [PATCH] Support for CSS classes in
cocoon forms XSL
[PATCH] Support for CSS classes in cocoon forms XSL
---------------------------------------------------
Key: COCOON-1782
URL: http://issues.apache.org/jira/browse/COCOON-1782
Project: Cocoon
Type: Improvement
Components: Blocks: Forms
Reporter: Simone Gianni
Attachments: 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 classes.
- <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 etc..).
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 fi:group
- <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 :
table.group.columns {
border: 1px solid blue;
}
table.group.columns td {
background: yellow;
}
table.group.columns 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [jira] Closed: (COCOON-1782) [PATCH] Support for CSS classes
in cocoon forms XSL
Posted by hepabolu <he...@gmail.com>.
Simone Gianni said the following on 09-05-2006 00:37:
> Thanks Helma,
> I can't properly understand what has to be done on documentation :
> - should legacy docs be moved to the new structure?
Currently the legacy docs are used for the current Cocoon version i.e.
2.1.X. There are scripts that export the information from Daisy into the
current version of the website.
The documentation collection/site will be used for the next Cocoon
version 2.2, 3.0 or whatever the new release number will be. We can
totally rearrange the documentation structure then if we want to.
When information currently in the legacy docs, is also valid for the new
version of Cocoon, you can simply add the "documentation" collection to
the document.
> - will the new structure be published on the site instead of the current
> docs?
I think that eventually, when 2.1.X goes in maintenance mode, the
current site will no longer be updated and the new 2.X/3.0 site will be
added and extracted in much the same way we do now with the 2.1.X site.
> - does it have any meaning to "backport" modifications to the legacy docs?
Yes, you will enhance the value of the document and bring it up to date
for the 2.1.X branch.
> Is there a "documentation status page" or something similar?
No, I don't think so. I've been meaning to start some Jira issues on
what documentation tasks there are to be done, but I'm swamped here so I
never seem to get round to do this.
> Also, there is something weird in daisy on cocoon zones : when I look at
> a document somebody modified i can see "you are looking at the live
> version of this document, which is currently not the last version", but
> if i click on the "last version" link, i still see the same document,
> only the warning at the top of the page changes. I can see the last
> version only if I edit it. Is this the expected behaviour? This caused
> me a kind of shock the first time, I thought all I wrote has been lost :)
It does sound a bit weird that you don't see the true last version of
the document, but you need to contact the Outerthought boys on that, I
have no clue what could be wrong.
Bye, Helma
Re: [jira] Closed: (COCOON-1782) [PATCH] Support for CSS classes
in cocoon forms XSL
Posted by Simone Gianni <s....@thebug.it>.
Thanks Helma,
I can't properly understand what has to be done on documentation :
- should legacy docs be moved to the new structure?
- will the new structure be published on the site instead of the current
docs?
- does it have any meaning to "backport" modifications to the legacy docs?
Is there a "documentation status page" or something similar?
Also, there is something weird in daisy on cocoon zones : when I look at
a document somebody modified i can see "you are looking at the live
version of this document, which is currently not the last version", but
if i click on the "last version" link, i still see the same document,
only the warning at the top of the page changes. I can see the last
version only if I edit it. Is this the expected behaviour? This caused
me a kind of shock the first time, I thought all I wrote has been lost :)
Simone
Re: [jira] Closed: (COCOON-1782) [PATCH] Support for CSS classes in cocoon forms XSL
Posted by hepabolu <he...@gmail.com>.
On 5/8/06, Simone Gianni (JIRA) <ji...@apache.org> wrote:
> [ http://issues.apache.org/jira/browse/COCOON-1782?page=all ]
>
> Simone Gianni closed COCOON-1782:
> ---------------------------------
> Also added documentation on zones, but not added to the tree since seems like i cannot untile the document gets published.
Simone,
I assigened the doc-committer role to you, so you are now able to
publish your own documents.
--
Bye, hepabolu
[jira] Closed: (COCOON-1782) [PATCH] Support for CSS classes in
cocoon forms XSL
Posted by "Simone Gianni (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/COCOON-1782?page=all ]
Simone Gianni closed COCOON-1782:
---------------------------------
Fix Version: 2.1.10-dev (current SVN)
Resolution: Fixed
Also added documentation on zones, but not added to the tree since seems like i cannot untile the document gets published.
> [PATCH] Support for CSS classes in cocoon forms XSL
> ---------------------------------------------------
>
> Key: COCOON-1782
> URL: http://issues.apache.org/jira/browse/COCOON-1782
> Project: Cocoon
> Type: Improvement
> Components: Blocks: Forms
> Reporter: Simone Gianni
> Assignee: Simone Gianni
> Fix For: 2.1.10-dev (current SVN)
> 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 classes.
> - <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 etc..).
> 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 fi:group
> - <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 :
> table.group.columns {
> border: 1px solid blue;
> }
> table.group.columns td {
> background: yellow;
> }
> table.group.columns 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1782) [PATCH] Support for CSS classes in
cocoon forms XSL
Posted by "Simone Gianni (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/COCOON-1782?page=all ]
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: http://issues.apache.org/jira/browse/COCOON-1782
> 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 classes.
> - <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 etc..).
> 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 fi:group
> - <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 :
> table.group.columns {
> border: 1px solid blue;
> }
> table.group.columns td {
> background: yellow;
> }
> table.group.columns 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1782) [PATCH] Support for CSS classes in
cocoon forms XSL
Posted by "Simone Gianni (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/COCOON-1782?page=all ]
Simone Gianni updated COCOON-1782:
----------------------------------
Attachment: xsl-css-trunk.diff
Same patch to be applied to trunk.
> [PATCH] Support for CSS classes in cocoon forms XSL
> ---------------------------------------------------
>
> Key: COCOON-1782
> URL: http://issues.apache.org/jira/browse/COCOON-1782
> Project: Cocoon
> Type: Improvement
> Components: Blocks: Forms
> Reporter: Simone Gianni
> Attachments: 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 classes.
> - <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 etc..).
> 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 fi:group
> - <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 :
> table.group.columns {
> border: 1px solid blue;
> }
> table.group.columns td {
> background: yellow;
> }
> table.group.columns 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-1782) [PATCH] Support for CSS classes in
cocoon forms XSL
Posted by "Simone Gianni (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/COCOON-1782?page=all ]
Simone Gianni reassigned COCOON-1782:
-------------------------------------
Assign To: Simone Gianni
> [PATCH] Support for CSS classes in cocoon forms XSL
> ---------------------------------------------------
>
> Key: COCOON-1782
> URL: http://issues.apache.org/jira/browse/COCOON-1782
> Project: Cocoon
> Type: Improvement
> Components: Blocks: Forms
> Reporter: Simone Gianni
> Assignee: 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 classes.
> - <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 etc..).
> 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 fi:group
> - <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 :
> table.group.columns {
> border: 1px solid blue;
> }
> table.group.columns td {
> background: yellow;
> }
> table.group.columns 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira