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