Re: [RFC] Form Widget Stylings element || attribute

[David E. Jones]

-David


On Feb 24, 2007, at 3:38 PM, Jacques Le Roux 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.

Chris, Jacopo,



Jacques


----- Original Message -----
From: "Jacopo Cappellato" <[EMAIL PROTECTED]>
To: <dev@ofbiz.apache.org>
Sent: Saturday, February 24, 2007 6:23 PM
Subject: Re: [RFC] Form Widget Stylings element || attribute

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

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

settles on that refactoring, is it the goal to deprecate those 12
attributes from the form element or to support both?


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.


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

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.


end up writing their forms in less maintainable, less reusable
freemarker.


--- Jacopo Cappellato <[EMAIL PROTECTED]> wrote:

doubt that the definitions in the project will benefit from leveraging the technique that refactoring would support. But, when all the dust My view, if it's to deprecate, great, table this discussion as they'll It's a relatively simple change in the reader, and a simple migration 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 It also makes it daunting and difficult to learn for newbies and they

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

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


non specific style for the single form).

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.

decision/discussion on this after the refactoring/consolidation (see need to specify the styles in each form definition (unless you need a After this is done, the next (big) step will be that of removing the

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

the
direction, so I would prefer to avoid this if possible.



on
the same css classes of html output.
So ideally the css style should have a semantic meaning, that is


form definition should be the same.

Jacopo

conventions, such as the url definition above)... but this should be 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 rendered with different attributes for different media types, but the

smime.p7s
Description: S/MIME cryptographic signature