[RFC] Form Widget Stylings element || attribute
Locked
[RFC] Form Widget Stylings element || attribute
 
|
Re: [RFC] Form Widget Stylings element || attribute
|
|
Re: [RFC] Form Widget Stylings element || attribute
|
|
Re: [RFC] Form Widget Stylings element || attribute
|
|
Re: [RFC] Form Widget Stylings element || attribute
|
|
Re: [RFC] Form Widget Stylings element || attribute
|
|
Re: [RFC] Form Widget Stylings element || attribute
|
|
Re: [RFC] Form Widget Stylings element || attribute
|
|
Re: [RFC] Form Widget Stylings element || attribute
|
|
Re: [RFC] Form Widget Stylings element || attribute
|
|
Re: [RFC] Form Widget Stylings element || attribute
Administrator
|
Re: [RFC] Form Widget Stylings element || attribute
|
Administrator
|
Re: [RFC] Form Widget Stylings element || attribute
|
|
In reply to this post by Jacques Le Roux
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" <[hidden email]> > To: <[hidden email]> > 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 <[hidden email]> 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 >>>> >>>> >> > |
smime.p7s (3K)
Re: [RFC] Form Widget Stylings element || attribute
|
|
Re: [RFC] Form Widget Stylings element || attribute
|
|
Re: [RFC] Form Widget Stylings element || attribute
|
|
Re: [RFC] Form Widget Stylings element || attribute
|
|
Re: [RFC] Form Widget Stylings element || attribute
|
|
In reply to this post by Jacopo Cappellato
On Feb 26, 2007, at 1:05 AM, Jacopo Cappellato wrote: > David, > > David E. Jones wrote: >> ... >> 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 > > just to clarify this point: I was not suggesting to remove (or > deprecate) the style attributes from the xsd grammar; what I meant > was that, as soon as the form widgets element will be decorated > with default styles in css, we should remove the default style > attribute from the existing form definitions and just leave the > ones for non standard styles. Is this a good plan in your opinion? mentioned this because it sounded like others were misunderstanding what you proposed. -David |
| Free forum by Nabble | Edit this page |