ChristophDorn wrote:
I really like the idea of using the XUL standard for qooxdoo application
layout. It makes total sense. From what I have gathered so far it looks like
a good fit.
The IoC container approach from what I can gather would make most sense to
bring the application to life for the action and event system on the client
side, client to server and server to client?
IoC containers are most useful when combined with using interfaces (as
in OOP) and aspect oriented programming, as they provide a convenient
object factory that can instantiate, decorate and wire your objects
together. They also add value in being able to externalise configuration
and avoid having the Factory Pattern or Service Locator Pattern used
everywhere. Very nice and elegant, and indeed the entire Java community
is moving to IoC. The new J2EE EJB 3 specification, for example, is
heavily inspired by IoC containers.
I raised IoC within the Qooxdoo context as an alternative to adopting an
existing XML framework such as XUL. On balance, I think there is far
more value pursuing an XUL runtime - provided someone has time to
actually do it. For those people out there who haven't done much with
XUL, I would urge them to try out these two sample applications built
using XUL, which were only made public in the last few days:
http://www.ajaxwrite.com/
http://www.ajaxsketch.com/
If we can make an XUL runtime that uses the Qooxdoo engine instead of
FireFox, we'll have a good solution.
Having said all that, I very much like Qooxdoo as-is. It's very easy to
write decent applications in pure JavaScript, and use JSON-RPC manually.
The real value of some type of XML abstraction will be the tooling
support it delivers,
and clear separation of presentation logic (XUL) from controller logic
(JavaScript) and the model (obtained generally via JSON-RPC). This is
the Model View Controller Pattern we ended up with in other UI spaces,
including request-response web frameworks, so I can reason to strive for
it with Qooxdoo as well. XUL is nice as it saves us having to invent an
approach - we can just use their model.
Even if we don't write a fully compliant XUL engine, simply adopting the
structural approach (ie patterns) used by XUL, but with a simplified XML
schema that reflects Qooxdoo's present API, would be a significant step
in the right direction (and require considerably less effort than XUL).
Cheers
Ben
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
