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.
The user was locked. Login should work again now.
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.
How do you work with XML snippets from backend? I never tried inserting them into the GUI, but this feature is very interesting. I only parsed them for special return values.
* 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.
Another feature I don't know!! And I used current = current.parentNode and I hate it!! How to apply XPaths on the DOM?
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/
This is true: documentation is poor, wide spreaded and almost always to old. I used Google for searching for the interface names for guessing possible method names.
* 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.
XBL is a further very nice feature: encapsulating all the functionality of your widget! But: there is a zibbel monster slowing down the binding (http://groups.google.de/groups?hl=de&lr=&ie=UTF-8&newwindow=1&threadm=3e771852%240%2413420%243b214f66%40news.univie.ac.at&rnum=1&prev=/groups%3Fq%3Dmonster%2Bxbl%2Bgroup:netscape.*%2Bgroup:netscape.*%26hl%3Dde%26lr%3D%26ie%3DUTF-8%26newwindow%3D1%26group%3Dnetscape.*%26selm%3D3e771852%25240%252413420%25243b214f66%2540news.univie.ac.at%26rnum%3D1). I don't know if someone tried to fight against it in the meantime. Another problem was the JavaScript Debugger not able to jump into XBL files at that time.
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.
I'm really impressed. May I ask where you took all your XUL knowledge from?
Joerg
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
