Hi every one.
I have this concept that I would like to discuss it publicly, Please
reply with whatever feedback regarding this post weather you like it or
simply don't like where it's going at all.
I've developed a Proof of Concept project during my postgrad IT diploma
some 10 months ago. It was based mainly on the dynamic generation of
backend (JDBC/JDO/EJBs) and front ends (XUL based mainly + some HTMLs)
using JSP pages, the model and JSP pages were dynamically generated
based on an import of a graph-structured data model.
as a proof of concept I reached a reasonable magnitude in the
implementation. however, there were few suggestions, remarks. that I
think would make building Mozilla based client applications an upper
choice for most of us.
I read a post here
(http://aguiares.blogspot.com/2005/03/why-xul-should-stay-with-mozilla.html)
about a should-have-been XUL project but the author regretfully switches
to RCP (Eclipse Based Rich Client Platform) thin client, with no
intention to criticise the author's point of view but the article
generally motivated me to write this.
I have few suggestions regarding what can be a foundation for Rich
Client Application development Framework using Mozilla.
1. First the lack of cohesion between different windows/Java script
library sharing/ XMLHTTPRequest object lifespan and sharing issues:
Why won't there be a singleton (hidden) window that does the Controller
logic on the client side, that acts as a hub for common information
shared between different windows so operations like opening new windows,
caching objects for multiple listeners would be done via that hub with
dynamic registration schemes (let's say event based notification for
instance..)
2. the forementioned controller will also participate in
distributing/centralizing controller logic on the client side.
3. the same controller would be a callback point for server logic
(server controller) interacting with the client in bidi communication
(server notifing client) in scenarios like workitem creation relevant to
a certain user or any thing with multiple distributed user interactions
and tasks which can be usually simulated using frequent updates or
actual callbacks, that will be one way or another hidden from normal
browser windows by the centralization of event polling by this main
(propably hidden )window acting as a controller for the client side.
4. the document based model of client to first line servers logic is
generally an overhead the is candidate for centralization and facade
like interfaces within this client hub the main windows is supposed to
provide to other windows. again things like XMLHttpRequest are fine but
there can be simpler approaches.
5. I'm neither a XUL guru nor a Javascript guru, but I am profecient in
Java and J2EE architecture and I *know* if we restrict XUL interface
design and modelling to XSLT and XML document creation; Java nd Eclipse
in particular will be outstanding tools in achieving very handy toolset
in creation of UI composites and generation of generic UI logic in general.
don't get me wrong I believe Eclipse based RCP are simply frank winners
in areas. but if we compare the original idea of thin clients to RCP
based clients. I think Mozilla has a more natural role and a natural
advantage over RCP applications.
6. XUL specefic renderes can be integrated into J2EE application life
cycles either as plain JSP pages or custom Taglibs or (preferrably) as
JSF custom renderers.
what do you think ?
Please find the time to reply to whatever you think this document is or
should have been.
Mohamed
_______________________________________________
mozilla-embedding mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-embedding
