Martin Cooper wrote:
>I'm interested in your thoughts on how well this is really going to
work.
>For example, one toolkit might have a data grid that supports draggable
>column ordering and resizing, data binding, auto-pre-fetch, in-place
rich
>text editing, etc., while obviously not all toolkits are going to have
that
>support, so I can't just switch underlying toolkits (unless XAP is
going to
>provide the missing support ;). It doesn't have to be anything as fancy
as
>that - even simple features are likely to be implemented sufficiently
>differently across toolkits that a common interface won't work. And
most
>toolkits have different ideas about how layout and containers should
work,
>too. So does that mean that XAP will provide the lowest common
denominator
>in terms of functionality, or will switching toolkits just now work in
many
>cases?
>
(Again, my opinions, not necessarily Nexaweb's or {anyone else
there}'s:)
The implementation differences wouldn't be a problem, once a
toolkit-specific bridge (or a generic bridge and toolkit-specific
adapter in my proposed scheme) has been implemented. I also think a
generic component that handles layout and tries to handle peer
attributes via something like 'if(peer["foo"]){ peer["foo"]=value;} else
{<exception>}' (JS needs a Bean standard more than Java did) will be
useful
Different ideas about layout and containment are harder. I would say
that for simple and common elements, we should try to adapt their
behaviours such that the same xal produces the same layout for
each---but, as I said, I don't think the big basic toolkits will be
serious candidates for mashing up, it will be more a matter of a basic
toolkit that handles dhtml elements and additional toolkits for specific
functionality.
Let me be clear: with enough time and resources, I think it could be
done: we could have reasonable operability between individual
components from different basic toolkits. However, I think what I just
described {Zimbra XOR Dojo XOR ...} && (task-specific widgets) should be
our aim for now. The beauty of the open-source process here lies in the
potential that if enough people end up really wanting this and enough
clever and money and/or time-rich individuals agree....
Everyone: have a good weekend.
========================================================
M. Turyn
Software Engineer, Nexaweb Inc.
"Enterprise Web 2.0 Solutions - Thinner, Richer, Faster"
