* Brent L Johnson <[EMAIL PROTECTED]> [2003-10-30 00:47]:
> Wow I've never even heard of this - I guess using IE too
> much will do that to ya. I assume XUL is the XML format
> the browser frontend is written in to allow for different
> skins in Mozilla? I've heard the GUI is all in XML,
> but didnt realize you could utilize this for building
> web app gui's.
> I'd like to check it out - that login/pass that's in
> the mailing list thread does not work. Does anyone
> have any XUL examples I could check out? I like
> the idea of outputting XUL format using Cocoon
> to build a webapp frontend.
Then we should talk, because that is what I am doing right now.
Altough, for starters, I'm using XHTML to describe my interfaces.
Using XHTML I can create applications that look and feel like web
applications, but have a full cross-platform application framework
behind them.
Mozilla for IE DHTML programmers:
(Note for any bit here: If you point me to the page on the MSDN
that says I'm wrong, I won't repent. I'll never go back! Too
much time and energy wasted making IE do right by me. I deserve
better. I deserve Mozilla.)
* Everything is scriptable. EVERYTHING! The file system, the
network, the cache, encryption, menus, everything. Everything is
an XPCOM object, and all XPCOM objects are avialable to JavaScript.
I jumped ship when I found that the IE JScript file objects would
not save binary files (not even signed, not even hta). It would
save a file, sure, but CRLF if found, was molested. I was faced
with the prospect of writing an AciveX control just to keep a logo
handy. With Mozilla the file system is there though nsIFile and
friends (Java like IO API).
* Everything is XML. EVERYTHING! XML data islands? It is to laugh.
The UI is XHTML/XUL. Which means that they share the same DOM. It
you can use all of Cocoon's firepower. You can post XML content.
Receive XHTML/XUL snippets and insert them into your GUI for
dynamic rendering. The reuse is phenominal.
* The same DOM for both XML and XHTML/XUL. You can use XPath on your
html documents, which makes scripting widgets frighteningly easy.
How often do you write <tt>current = current.parentNode;</tt>
loops in IE? Finding the participants in a widget is simple with
XPath.
All the methods you write to simplify the processing of XML DOM
can now be applied to your document DOM.
XSLT is on tap for manipulating both XML and XHTML/XUL. It is,
however, very slow compared to Cocoon, which is why I am working
with Cocoon to generate displays (XHTML).
* Mozile:
http://www.oreillynet.com/pub/a/mozilla/2003/10/03/mozile.html
Mozilla annoyances:
* No project history, symanic web, collective memory. Most of the
devleoper discussion takes place in chat rooms. All those
discussions and decissions are lost. The newsgroups are very
lightly trafficed. There is not much blogging. There is an online
forum where the same silly questions are asked time and again.
This has got to be the biggest failing of the Mozilla project.
Google is near useless in Mozilla development.
* Little relevent documentation, oodles of irrelevent documentation,
all of where are poorly organized. It't not you.
You must read the code to understand Mozilla. Find some
documentation on XPCOM. Grok it. Then you can learn most of what
you need to know about XUL through a code read of the debugger,
Venkman, and the Calendar.
The lastest version of Mozilla itself, Firebird, shows the lastest
thinking in XUL.
http://lxr.mozilla.org/mozilla/source/browser/
Venkman and Calendar.
http://lxr.mozilla.org/mozilla/source/extensions/venkman/
http://lxr.mozilla.org/mozilla/source/calendar/
* XUL fanatics.
The compelling Mozilla features listed above are available to
XHTML just as they are available to XUL. It is even possible to
create XUL bindings to XHTML elements. Still, you'll find yourself
on the defensive if you talk about DHTML/XHTML.
This is a pity, since, for the most part, XUL applications tend to
look and feel like AWT applications. Grid layouts of grey buttons
and white select boxes. For most applications, The learning curve
for XUL is simply not worth the benifits of cascading menus and
skinnable controls.
More's the pity that IE developers, agog at Mozilla's abilities,
are never told that they can get most of what they want using
skills they've already developed by using MSXML. They are
discouraged from using those skills. They naturally return to
their proven tool set thinking, rightly, that Mozilla is still the
domain of enthusiasts.
XUL would be far more successful it the community would swallow
their pride and offer a migration path.
* XPCOM. As C++ it is very hard to read.
The return value is always a status code since exceptions are
forsaken.
This means that a natural function like:
nsString getName()
is really:
NS_RESULT getName(nsIString* pStringResult)
(or some such.)
No constructors either, everything is created through a factory.
Every object, therefore, provides an Init() method to provide the
information you'd ordinarily provide to the constructor.
Those two combined are enough to double the lines of code.
http://lxr.mozilla.org/mozilla/source/dom/src/base/nsHistory.cpp#126
Note how all those getter calls require two lines of code at
least? No RAII for in XPCOM.
Basically, all the misery of COM without anything like ATL to ease
the pain.
The payoff is that after you've suffered, your work is available
to JavaScript, which makes for excellent reuse. Is has payed off.
If Mozilla can encrypt a file, save a file, parse an XML document,
gopher query, play a sound, ldap query, then so can your
application via JavaScript.
I'm working on using Mozilla as a UI to a Cocoon application. It
would read and write XML documents. So let's talk.
--
Alain Javier Guarnieri del Gesu - [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
