-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 first, thank you all for your answers. It sounds it is a complex project to mix between all the frameworks. XAP must have knowledge of all possible integrations. Today i used some dojo stuff for my prime time webapp and found it difficult because lack of documentation and a bug. I could solve everything, but it needed time. Imaging that XAP must deal with all those things too- and with different frameworks- wow. If it can, great.
For the template question: Tiles was/is a struts-project and a template engine. It's nearly standalone now and i like it. See: * http://struts.apache.org/struts-action/struts-tiles/index.html For my question, will it be possible to include XAP scripts within other? In the example it looks like "one xal-file, one page". But maybe i would like to define menu.xal and include it in default.xal or something like that. I think i have to check out the stuff to understand more. Thanks all, Chris James Margaris wrote: > 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEpX1zkv8rKBUE/T4RAmwjAJ42dtXGEJBj5wjmR6SGY4nuybp0PwCdGqni NJ6aDM6Un81ByADKzjPUjvk= =v0J8 -----END PGP SIGNATURE-----
