About this conversation, it is my opinion that switching toolkits for the base widget set is very doable but in the end probably not all that useful for the end user. It may be that at some point if some far superior toolkit comes out we can use that one instead, the architecture allows for that fairly easily.
To me the main value is that the architecture keeps the UI manipulation stuff fairly self-contained from the real guts of the framework and makes it easy to add/integrate new widgets and packages. As I mentioned in the other email, an example of this might be a javascript charting package, a javascript vector-graphics package, a mapping widget, an auto-completion pulldown, or some sort of more specialized things. (more boutique-style widgets) A widget that allows you do zoom and move around an image, a HTML editing thing, a widget that automates some blog stuff, who knows... As Michael said, additional toolkits for additional functionality. James Margaris -----Original Message----- From: Michael Turyn [mailto:[EMAIL PROTECTED] Sent: Friday, June 30, 2006 1:04 PM To: [email protected] Subject: RE: Scope and Templating 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"
