Would OFBIZ-671 eventually deprecate many of the attributes or simply make for an additional option when defining the form definition?
I can certainly see OFBIZ-671 being a "best practice" of sorts, but the current attributes would likely still be supported and the need for organization would still be there. Would perhaps the following be beneficial <form> <styling> <currentHtmlTechnique/> <bestPracticeHtmlTechnique/> <pdf/> </styling> </form> but with better element names? --- Adrian Crum <[EMAIL PROTECTED]> wrote: > 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? > >>> > >> > > > > >
