We're on the same page. If you specify a form style element, that style could
style all of the elements contained in the form. Therefore most of those
elements you listed aren't needed.
Chris Howe wrote:
Just to make sure we're on the same page... These are the attributes
that I would like comment on moving into a <styling> element
form-title-area-style
form-widget-area-style
default-title-area-style
default-widget-area-style
default-title-style
default-widget-style
default-tooltip-style
default-required-field-style
odd-row-style
even-row-style
header-row-style
default-table-style
OFBIZ-671 appears to add three more.
id
style
widget-focus
Which is great. The cool thing about the form widget is the amount of
specificity and control you can have and more will probably be needed
as people play with the ajax frameworks.
I'm suggesting that we pull those attributes out of the form definition
and put them in a styling element that is a child to the form element.
I'm not suggesting messing with the functionality, just the
organization.
I get lost, especially with IDEs that use code complete, finding the
attribute I need.
Separating the pagination attributes into a <pagination> child element
may be beneficial as well as there are about 10 of those that would
make a natural grouping.
--- Adrian Crum <[EMAIL PROTECTED]> wrote:
Chris,
I just refactored the form widget. Take a look:
https://issues.apache.org/jira/browse/OFBIZ-671
This will eliminate a lot of property assignments.
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>
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?
