Minor enhancement to Form widget, will help in while working with them from Javascript
Locked
Minor enhancement to Form widget, will help in while working with them from Javascript
 
|
Re: Minor enhancement to Form widget, will help in while working with them from Javascript
|
|
Re: Minor enhancement to Form widget, will help in while working with them from Javascript
|
|
Re: Minor enhancement to Form widget, will help in while working with them from Javascript
|
|
The concept you are talking about is correct in general Adrian, but means something different than your interpretation here. The intent of the screen, form and other widgets is to define structure and business level artifacts (not technical or visual). They are meant to be externally styled, hence the use of "style" attributes, and yes even "id" attributes. In other words, certain elements in the screen and form widgets (didn't check the others) already DO have id attributes on them, and if necessary we could add it to others as well. -David On Nov 26, 2007, at 9:14 AM, Adrian Crum wrote: > I had suggested adding the ID attribute (and others) to all widget > elements earlier this year. The response was that we shouldn't tie > widget code too closely to HTML output, since the intent is to use > widgets to render to more than one output format. > > -Adrian > > Jonathon -- Improov wrote: > >> I did this on a private Widget Engine enhancement, along with AJAX. >> Unfortunately, that enhancement was licensed private months ago. >> Sorry. >> Frankly, I don't think the "id" attribute is really great. It's >> always possible, maybe even preferable, to reference HTML elements >> in a structured DOM way. >> I'd be willing to discuss this further if some of us are committed >> to working on this and putting it back to OFBiz. >> Jonathon >> Anil Patel wrote: >>> Hi, >>> Some Form Widget elements don't have "id" attribute. Id on html >>> elements >>> makes them lot easier to work with from Javascript. I'll >>> appreciate If >>> somebody evaluate possibility of having id attribute on all form >>> widget >>> elements and possibly implement them. >>> >>> Regards >>> Anil Patel > |
smime.p7s (3K)
Re: Minor enhancement to Form widget, will help in while working with them from Javascript
|
|
Re: Minor enhancement to Form widget, will help in while working with them from Javascript
|
|
It sounds like a good pattern, but which classes would extend from this base class? For the form widget there are a few places that could use an id. These SHOULD follow the same pattern as the "*style" attributes, but evidently whoever added them didn't feel the need... or perhaps didn't like the pattern? Anyway, for example on the field element the attribute is called "id- name", though it really should be "widget-id" and there really SHOULD be other attributes that go along with it like "title-id" and possibly others like "widget-area-id" and "title-area-id". In fact, I hadn't looked at this in detail before but looking at it now the inconsistency and confusion (perhaps causing this thread even?) bother me and I'd like to see the "id-name" attribute removed (pulled from the XSD, still supported in the parsing code, just like in many other places so we get a warning, or parse error really, but it will still work). Is anyone working on this, or interested in doing so in the near future (before the coming waves of other topics wash this out ;) )? -David On Nov 26, 2007, at 12:03 PM, Adrian Crum wrote: > David, > > Thank you for the clarification. I also suggested at the time that > all of the widgets could be extended from a simple base class that > contains common attributes like style, id, etc. > > -Adrian > > David E Jones wrote: > >> The concept you are talking about is correct in general Adrian, >> but means something different than your interpretation here. The >> intent of the screen, form and other widgets is to define >> structure and business level artifacts (not technical or visual). >> They are meant to be externally styled, hence the use of "style" >> attributes, and yes even "id" attributes. >> In other words, certain elements in the screen and form widgets >> (didn't check the others) already DO have id attributes on them, >> and if necessary we could add it to others as well. >> -David >> On Nov 26, 2007, at 9:14 AM, Adrian Crum wrote: >>> I had suggested adding the ID attribute (and others) to all >>> widget elements earlier this year. The response was that we >>> shouldn't tie widget code too closely to HTML output, since the >>> intent is to use widgets to render to more than one output format. >>> >>> -Adrian >>> >>> Jonathon -- Improov wrote: >>> >>>> I did this on a private Widget Engine enhancement, along with >>>> AJAX. Unfortunately, that enhancement was licensed private >>>> months ago. Sorry. >>>> Frankly, I don't think the "id" attribute is really great. It's >>>> always possible, maybe even preferable, to reference HTML >>>> elements in a structured DOM way. >>>> I'd be willing to discuss this further if some of us are >>>> committed to working on this and putting it back to OFBiz. >>>> Jonathon >>>> Anil Patel wrote: >>>> >>>>> Hi, >>>>> Some Form Widget elements don't have "id" attribute. Id on html >>>>> elements >>>>> makes them lot easier to work with from Javascript. I'll >>>>> appreciate If >>>>> somebody evaluate possibility of having id attribute on all >>>>> form widget >>>>> elements and possibly implement them. >>>>> >>>>> Regards >>>>> Anil Patel >>> >>> > |
Re: Minor enhancement to Form widget, will help in while working with them from Javascript
|
|
Re: Minor enhancement to Form widget, will help in while working with them from Javascript
|
|
| Free forum by Nabble | Edit this page |