Adrian,
I remember your suggestion to base the widgets from a single abstract class. I liked it. Just
that, it was so inconsistent, I didn't know where to start. I also haven't given much thought to
exactly what that "base class" should be.
I think you're the best person now to manage this implementation. Let me know
how I can help.
Jonathon
Adrian Crum wrote:
I agree - the implementation is inconsistent and confusing.
I would like to work on it.
-Adrian
David E Jones wrote:
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
