Chris,
Chris Howe wrote:
For me the one thing that is holding me back the most from using form
widgets more pervasively is that there are 40+ attributes for the form
element.
Request for comment:
1. Would the form widget be better off with moving the styling
attributes into a subelement as opposed to being attributes of the
<form> tag ie:
<form>
<styling/>
<actions/>
<field/>
</form>
This idea is a probably interesting one, but I'd suggest to delay any
decision/discussion on this after the refactoring/consolidation (see
also Adrian's comments) effort is done.
I'm saying this because I think that, after this work is done, the
default styles used by the widgets will be in css and there will be no
need to specify the styles in each form definition (unless you need a
non specific style for the single form).
After this is done, the next (big) step will be that of removing the
default (unnecessary) styles from all the form definitions in the system.
For example, a form like this one:
<form name="ListExamples"
type="list" list-name="examples"
paginate-target="FindExample"
default-title-style="tableheadtext"
default-widget-style="tabletext"
default-tooltip-style="tabletext">
<field name="exampleId"
title="${uiLabelMap.ExampleExampleId}"
widget-style="buttontext">
<hyperlink also-hidden="false"
description="${exampleId}"
target="EditExample?exampleId=${exampleId}"/>
</field>
</form>
Will could be simplified in the following way:
<form name="ListExamples"
type="list" list-name="examples"
paginate-target="FindExample">
<field name="exampleId"
title="${uiLabelMap.ExampleExampleId}">
<hyperlink also-hidden="false"
description="${exampleId}"
target="EditExample?exampleId=${exampleId}"/>
</field>
</form>
After these tasks are completed, we can return on this subject and
discuss what you are proposing.
2. If 1, then would it make sense to make a subelement to styling to
account for different media (html vs pdf) or has the pdf styling
already been accomplished well?
In theory, form definitions should be abstracted from the media type: I
know that many of them contain html specific code (or at least
conventions, such as the url definition above)... but this should be the
direction, so I would prefer to avoid this if possible.
About the styles for pdf output from widgets: right now they are very
simply defined in a properties file but the key in the file are based on
the same css classes of html output.
So ideally the css style should have a semantic meaning, that is
rendered with different attributes for different media types, but the
form definition should be the same.
Jacopo
