David E Jones <[EMAIL PROTECTED]> wrote: > I hadn't gotten to the widget XML
side of things yet. The ideas I've
> had so far try to keep within the constraint that the widget XML
> files should be rendering-platform independent. I don't have any
> specifics yet, but the general idea I had in mind was to keep the
> existing widget elements, but have an additional element attribute
> that allows developers to pass library-specific data to the
> rendering classes.
Wouldn't that right there break the whole idea of being rendering
platform independent?
No, I don't think so. My thinking is, I'd like to avoid another set of elements
like the <platform--dependent> ones. For example, the existing container
element could have something like
<container id="some-id" style="some-style" dojo="some Dojo data">
...
</container>
So, there is some data there to accomodate a third party library, but the
element itself remains platform independent - other rendering methods simply
ignore the dojo attribute.
On the other hand, something like
<some-dojo-element>
...
</some-dojo-element>
creates a problem. What do other rendering methods do in that scenario? Do we
need to have corresponding non-dojo sets of elements in the same screen
definition?
I agree we need to discuss how this should look in XML before any more work is
done. I'll start another thread to get that discussion going. But I still
believe, regardless of how the XML code looks in the end, we'll need a factory
method to create rendering classes. ;-)
-Adrian
---------------------------------
Looking for last minute shopping deals? Find them fast with Yahoo! Search.
