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 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 > >> > >> >
