* Joerg Heinicke <[EMAIL PROTECTED]> [2003-10-30 17:50]:
> On 30.10.2003 16:55, Alain Javier Guarnieri del Gesu wrote:
>
> >>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.
>
> >Mozilla for IE DHTML programmers:
> >* 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.
Maybe we are talking about different things. Here is one way I use
Cocoon to generate nifty components and insert them into a document.
The problem is one of choose an item from a heirarcical controled
vocabulary that is too large to keep in document. Like a every car
in the NADA blue book.
var http = new XMLHttpRequest()
// Now that we have make and year, call Cocoon to generate a fancy
// pick list with images of the models for that make and year.
var uri = "select-car-model.xhtml?make=" + make + "&year=" + year
http.open("GET", uri, false) // false => async
http.send(null)
if (http.status == 200) {
var widget = document.importNode(http.responseXML.documentElement, true)
var whereTo = document.getElementById("select-car-model")
whereTo.replaceChild(widget, whereTo.firstChild)
} else {
throw "Cannot find models for " + make + " in " + year +
": " + http.status + " (" + http.statusText + ")"
}
> >* 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?
Give an XHTML document and a context node to find the parent table
row, if you wanted to change the class name for example:
var result = document.evaluate("ancestor-or-self::xhtml:tr",
contextNode,
document.createNSResolver(
document.documentElement),
XPathResult.FIRST_ORDERED_NODE_TYPE,
null)
var tr = result.getSingleNodeValue()
Where:
XPath => "ancestor-or-self::xhtml:tr"
Search context => contextNode
XPathNSResolver => document.createNSResolver(document.documentElement)
^^ The namespace resolver is just that, a prefix to namespace
uri table. The createNSResolver method creates a lookup
table using the xmlns attributes of the element provided.
Result type => XPathResult.FIRST_ORDERED_NODE_TYPE
^^ Ten different types includeing NUMBER_TYPE, STRING_TYPE, etc.
Recycled XPathResult => null
^^ Reuse an existing XPathResult. Why? Don't know. I never do.
Its a mouthful. Most people use the prototype feature to define a
shortcut method ala select single node.
Element.prototype.selectSingleNode = function (xpath) {
var doc = this.ownerDocument
return doc.evaluate(xpath
this,
doc.createNSResolver(doc.documentElement),
XPathResult.FIRST_ORDERED_NODE_TYPE,
null).getSingleNodeValue()
}
Thus:
var tr = contextNode.selectSingleNode("ancestor-or-self::xhtml:tr")
if (tr != null) tr.className = "row-highlight"
This is W3 interface as defined here:
http://www.w3.org/TR/2003/CR-DOM-Level-3-XPath-20030331/
> >Mozilla annoyances:
> >* Little relevent documentation, oodles of irrelevent documentation,
> > all of where are poorly organized. It't not you.
> >
> 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.
I use a recursive grep on the source code. Searching the idl for the
method declarations and the js for examples of implementation. The
best documentation there is.
Google is very poor since there is nothing for it to index.
Development dicussion for Mozilla takes place on IRC. All that
knowledge is lost. It is amazing how much damage this is doing to
the Mozilla project. A mailing list is an indespensible resource for
an open-source project. The documentation flows from it. Since there
is no mailing list, there is no documentation.
>>* 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://google.groups.de/groups?threadm=3e771852%240%2413420%243b214f66%40news.univie.ac.at
> 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.
Fanatics, I tell you! Let them slay the Zibble monster. In the mean
time let them accept that there are better and more stable ways to
apply XML/DOM/XHTML in Mozilla.
Mozilla supports DOM Level 3 Events. It is a bubble model that is
comperable to the IE bubble model, its just a little cleaner.
http://www.w3.org/TR/2003/WD-DOM-Level-3-Events-20030331/
Read the spec, then marvel at the fact that Mozilla implements all
of this. Bonus: Its fast!
Oy! What are the XUL people thinking? Attaching a script to each and
every widget on a page is going to incur more overhead than routing
those events to a single handler that takes the event/widget as a
parmeter (IE behaviors are also slow). I'm sure they will sort it
all out in the end, but in the mean time a lot of thought has gone
into DOM 3, which is working splendidly, now.
Such a pity that IE developers are not told that there is an event
model that this refinded, fast, and familiar that they can adopt
now, while Mozilla bindings find their way.
> I'm really impressed. May I ask where you took all your XUL
> knowledge from?
It is interesting to see the results of your investigation into
Mozilla. I develop to Mozilla's open standard support, XHTML, CSS,
w3 DOM, XPath, and such. I now remember being discouraged at first,
thinking I had to learn a maze of new, and unstable APIs to use
Mozilla.
I wonder myself how I managed to look past it and adopt open
standards. Really, I don't want to develop widget based
applications, with menus, sliders, tool bars. I want to develop
document centric applications. For that I want to use a document
centric development environment (Cocoon/XHTML/CSS) not a GUI centic
development environment (XUL).
XUL has its place. For the implementation of a browser shell it is
magic. The Mozilla project seems to forget that they also have
browser. (Mozile/Midas seems to have awoken new interest in the
document side of Mozilla, however.)
http://www.oreillynet.com/pub/a/mozilla/2003/10/03/mozile.html
I want to see Mozilla play nice with Cocoon.
Why not create a Mozilla section on the Wiki? Perhaps Mozilla will
benefit from the perspective of developers that are not pouring
their energies into making XUL.
--
Alain Javier Guarnieri del Gesu - [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
