I believe I've taken care of both of your concerns. bit of work: FormArrangement.patch in OFBIZ-760 takes care of about 90% of the coding effort necessary in all OFBiz forms by moving the styling attributes to their own line in each form definition and then the pagination attributes to a line below that so that they can readily be separated into their own element groupings.
backwards compatibility: FormWidget.patch in OFBIZ-762 removes the pagination and styling attributes from the widget-form.xsd and moves them to a child element (<styling> and <paginate>) and will thusly throw errors if those attributes continue to exist in the <form> element in the definition. However, the ModelForm.java changes will allow either to exist and should still render the form as currently defined in svn. All that is needed to complete this is 1. a consensus (vote?) that this is a good change 2. adding the appropriate tag at the beginning of the separated lines. (relatively quick work because they all styling lines begin with " default-title-style=" and pagination lines begin with " paginate" ) 3. adding a log message to ModelForm.java when one of those attributes is used in the <form> element --- "David E. Jones" <[EMAIL PROTECTED]> wrote: > > There are other things to consider with this, like backwards > compatibility. What seems like an improvement to one may be a pain > for another. More applicable to this situation, what might seem like > > a convenience for one person may be an inconvenience for another. > > I guess the main thing is that I agree there will be a small > improvement in productivity if these are better organized, and the > coding effort isn't too big, but the refactoring of current artifacts > > would be a bit of work, and it would also cause problems for any > external code bases that use these. > > On the issue of eventually removing these... even if we come up with > > a good way of creating defaults in CSS (which I'm sure will work out > > fine) I don't think we'll want to remove these. Cases may, or are > likely to, arise where these will be of value. > > -David > > > On Feb 24, 2007, at 3:38 PM, Jacques Le Roux wrote: > > > Chris, Jacopo, > > > > At first sight I agree with Chris. In a general way a too high > > number of attributes is uneasy to deal with when using code > complete > > tools. If I understand ritght, even after the refactoring/ > > consolidation these elements will stay as form attributes (because > of > > Jacopo's sentence "unless you need a non specific style for the > > single form"). So why not tackle this right now and create forms > > sub-elements as Chris proposed ? For the moment, this is more a > > question than a vote for... though a little inclination for... > > > > Jacques > > > > > > ----- Original Message ----- > > From: "Jacopo Cappellato" <[EMAIL PROTECTED]> > > To: <[email protected]> > > Sent: Saturday, February 24, 2007 6:23 PM > > Subject: Re: [RFC] Form Widget Stylings element || attribute > > > > > >> Chris, > >> > >> I understand what you mean, but I don't know, I don't really have > a > >> strong opinion on this so I'd like to get also feedback from > others. > >> > >> Jacopo > >> > >> Chris Howe wrote: > >>> Jacopo, > >>> > >>> I completely agree with the direction or the refactoring and have > no > >>> doubt that the definitions in the project will benefit from > >>> leveraging > >>> the technique that refactoring would support. But, when all the > > >>> dust > >>> settles on that refactoring, is it the goal to deprecate those 12 > >>> attributes from the form element or to support both? > >>> > >>> My view, if it's to deprecate, great, table this discussion as > >>> they'll > >>> be out of the xsd soon enough and changing the reader and xsd > would > >>> likely be a wasted effort. But if it's to support both (and th > >>> reorganization in this RFC is supported), why not go ahead and > move > >>> those attributes to a child element. > >>> > >>> It's a relatively simple change in the reader, and a simple > >>> migration > >>> in the form definitions, that when done, will even make testing > >>> Adrian's refactoring easier as you can simply comment out the > entire > >>> <styling> element to see the difference with the form controlled > >>> styling and the screen controlled styling. > >>> > >>> In either case, it still leaves the suggestion of migrating out > the > >>> pagination attributes into a child element as well. When you have > > >>> these > >>> large natural groupings, I think it makes sense to move them to > >>> child > >>> elements as keeping them in the <form> element makes it > unproductive > >>> to search through a list of 35-45 attributes to find the one > you're > >>> interested in. > >>> > >>> It also makes it daunting and difficult to learn for newbies and > > >>> they > >>> end up writing their forms in less maintainable, less reusable > >>> freemarker. > >>> > >>> > >>> --- Jacopo Cappellato <[EMAIL PROTECTED]> wrote: > >>> > >>>> 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 > > === message truncated ===
