You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Antonio Gallardo <ag...@agsoftware.dnsalias.com> on 2003/10/30 02:09:09 UTC
[OT?] - XUL
Hi:
I found this interesting article:
http://linuxtoday.com/developer/2003102900426OSHLDV
I am wondering if we can provide support for this in Cocoon. As always,
comments are very welcomed. :-)
Best Regards,
Antonio Gallardo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [OT?] - XUL
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Oleg Dulin dijo:
> I slaved over a pretty big XUL application earlier this year using
> Mozilla as a run time environment.
>
> Just want to point something out:
>
> * XUL is just another XML format
> * XUL is an interactive-client side technology, as opposed to mostly
> static Xhtml. Cocoon/COcoon Forms/Woody is an interactive server side
> technology. Getting the two to work together would be useful, but I am
> just not sure if there is anything Cocoon can contribute. There already
> are ways to invoke XML web services from JavaScript from within a XUL
> app. * From Cocoon standpoint, nothing changes
> * There are no good XUL books, the ones that exist don't go deep enough
> to be useful
> * If Cocoon developers do find a need to add XUL support to Cocoon, I'd
> try and make it as Mozilla-independent as possible so that non-Mozilla
> XUL renderer plugins can be used. For example, going back to my XForms
> post earlier, XUL/JavaScript can be used to render XForms on the client
> side.
Well it depends. In our case, we build intranets webapp where you have
full control on every client your application servers. For this reason if
the app depends on Mozilla or not is not the point. You can see XUL as a
FAT client while using thin client advantage. Also as Linux on the Desktop
is a near reality. Mozilla or Firebird is a good bet here: Using it in
Windows while you are there and then switch to Linux when you will do the
migration.
> My personal opinion is that Cocoon does not need any special support for
> XUL, but that is because I cannot think of a scenario where Cocoon
> would be of help aside from providing backend XML web services and,
> possibly, rendering screens.
Yep. This is a good scenario. Another could be MVC while using a set of
small XUL applications.
Anyway I just posted an interesting article. Maybe next year I will try to
play with this stuff.
Best Regards,
Antonio Gallardo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [OT?] - XUL
Posted by Oleg Dulin <du...@olegdulin.com>.
Here: http://luxor-xul.sourceforge.net/
Basically, what I am saying is that if Cocoon ends up having built-in
support for XUL non-Mozilla implementations should be kept in consideration.
Kind regards,
Oleg
Oleg Dulin wrote:
> I slaved over a pretty big XUL application earlier this year using
> Mozilla as a run time environment.
>
> Just want to point something out:
>
> * XUL is just another XML format
> * XUL is an interactive-client side technology, as opposed to mostly
> static Xhtml. Cocoon/COcoon Forms/Woody is an interactive server side
> technology. Getting the two to work together would be useful, but I am
> just not sure if there is anything Cocoon can contribute. There already
> are ways to invoke XML web services from JavaScript from within a XUL app.
> * From Cocoon standpoint, nothing changes
> * There are no good XUL books, the ones that exist don't go deep enough
> to be useful
> * If Cocoon developers do find a need to add XUL support to Cocoon, I'd
> try and make it as Mozilla-independent as possible so that non-Mozilla
> XUL renderer plugins can be used. For example, going back to my XForms
> post earlier, XUL/JavaScript can be used to render XForms on the client
> side.
>
> My personal opinion is that Cocoon does not need any special support for
> XUL, but that is because I cannot think of a scenario where Cocoon would
> be of help aside from providing backend XML web services and, possibly,
> rendering screens.
>
> Oleg
>
> Antonio Gallardo wrote:
>
>> Hi:
>>
>> I found this interesting article:
>>
>> http://linuxtoday.com/developer/2003102900426OSHLDV
>>
>> I am wondering if we can provide support for this in Cocoon. As always,
>> comments are very welcomed. :-)
>>
>> Best Regards,
>>
>> Antonio Gallardo
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>> For additional commands, e-mail: users-help@cocoon.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [OT?] - XUL
Posted by Oleg Dulin <du...@olegdulin.com>.
I slaved over a pretty big XUL application earlier this year using
Mozilla as a run time environment.
Just want to point something out:
* XUL is just another XML format
* XUL is an interactive-client side technology, as opposed to mostly
static Xhtml. Cocoon/COcoon Forms/Woody is an interactive server side
technology. Getting the two to work together would be useful, but I am
just not sure if there is anything Cocoon can contribute. There already
are ways to invoke XML web services from JavaScript from within a XUL app.
* From Cocoon standpoint, nothing changes
* There are no good XUL books, the ones that exist don't go deep enough
to be useful
* If Cocoon developers do find a need to add XUL support to Cocoon, I'd
try and make it as Mozilla-independent as possible so that non-Mozilla
XUL renderer plugins can be used. For example, going back to my XForms
post earlier, XUL/JavaScript can be used to render XForms on the client
side.
My personal opinion is that Cocoon does not need any special support for
XUL, but that is because I cannot think of a scenario where Cocoon would
be of help aside from providing backend XML web services and, possibly,
rendering screens.
Oleg
Antonio Gallardo wrote:
> Hi:
>
> I found this interesting article:
>
> http://linuxtoday.com/developer/2003102900426OSHLDV
>
> I am wondering if we can provide support for this in Cocoon. As always,
> comments are very welcomed. :-)
>
> Best Regards,
>
> Antonio Gallardo
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: [OT?] - XUL
Posted by Reinhard Poetz <re...@apache.org>.
Thanks for the summary, it's wikified ;-)
see http://wiki.cocoondev.org/Wiki.jsp?page=XUL
Cheers,
Reinhard
> -----Original Message-----
> From: Chris Wilkes [mailto:cwilkes-cocoon@ladro.com]
> Sent: Thursday, October 30, 2003 7:43 AM
> To: users@cocoon.apache.org
> Subject: Re: [OT?] - XUL
>
>
> On Wed, Oct 29, 2003 at 11:47:51PM -0500, Brent L Johnson 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.
>
> You can download the example from the article
> http://www-106.ibm.com/developerworks/web/library/wa-appmozx/
> You can try out the Xul Tutorial at the xulplanet site:
> http://www.xulplanet.com/tutorials/xultu/
> Another good place to look at the Mozilla Development site
> http://mozdev.org/
>
> I tried to use
> http://xulmaker.mozdev.org/
> but it crashed my Mozilla 1.5. Looks interesting though.
>
> There's another competing package out there called Luxor Xul
> http://luxor-xul.sourceforge.net/
>
> You'll have to brush up on your javascript as that's used to
> make it more stand alone GUI like. Now if there was just an
> easy javascript creator and/or GUI ...
>
> Chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [OT?] - XUL
Posted by Chris Wilkes <cw...@ladro.com>.
On Wed, Oct 29, 2003 at 11:47:51PM -0500, Brent L Johnson 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.
You can download the example from the article
http://www-106.ibm.com/developerworks/web/library/wa-appmozx/
You can try out the Xul Tutorial at the xulplanet site:
http://www.xulplanet.com/tutorials/xultu/
Another good place to look at the Mozilla Development site
http://mozdev.org/
I tried to use
http://xulmaker.mozdev.org/
but it crashed my Mozilla 1.5. Looks interesting though.
There's another competing package out there called Luxor Xul
http://luxor-xul.sourceforge.net/
You'll have to brush up on your javascript as that's used to make it
more stand alone GUI like. Now if there was just an easy javascript
creator and/or GUI ...
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [OT?] - XUL
Posted by Alain Javier Guarnieri del Gesu <ja...@ajgdg.com>.
* Joerg Heinicke <jh...@virbus.de> [2003-10-30 04:41]:
> On 30.10.2003 02:54, Antonio Gallardo wrote:
> >Joerg Heinicke dijo:
> >
> >>It's not that difficult, it's "just another markup language".
> >>
> >>Not long ago I announced our ConWeb application based on XUL:
> >>http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=106448993524514&w=2.
> >>As you can read this is already based on Cocoon
> >
> >
> >BTW, can you recommend any XUL book? I will like to go a little in depth
> >with XUL.
<snip gist="No good books" concur="true"/>
> The also available JavaScript Debugger reached never the status of being
> really helpful during our development, but it could have changed in the
> meantime.
Yes. Ready for prime time, so long as you have a quick machine.
It is written entirely in XUL and Javascript, so it is a good
example of how to write a XUL application.
--
Alain Javier Guarnieri del Gesu - javi@ajgdg.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [OT?] - XUL
Posted by Joerg Heinicke <jh...@virbus.de>.
On 30.10.2003 09:42, Joerg Heinicke wrote:
> the DOM inspector (per default delivered with Cocoon, Tools > Web Development > DOM Inspector)
> the JavaScript Console (also delivered with Cocoon, Tools > Web Development > JavaScript Console)
of course not with Cocoon, but with Mozilla.
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [OT?] - XUL
Posted by Joerg Heinicke <jh...@virbus.de>.
On 30.10.2003 02:54, Antonio Gallardo wrote:
> Joerg Heinicke dijo:
>
>>It's not that difficult, it's "just another markup language".
>>
>>Not long ago I announced our ConWeb application based on XUL:
>>http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=106448993524514&w=2.
>>As you can read this is already based on Cocoon
>
>
> BTW, can you recommend any XUL book? I will like to go a little in depth
> with XUL.
One book is available online for free: http://books.mozdev.org/, but I
can not really recommend it. On the one hand the books are to old, the
development on the Mozilla project is to fast. On the other hand they
don't go deep enough, i.e. if you create a "real" application you won't
find the information in such a book.
The best resource is xulplanet.com with its tutorial for a good start
and later the element reference. The FAQ and the XPCom reference didn't
exist at the time we build the application, but they seem to be
interesting to.
*Very* helpful are the prefbar (for adding buttons like "clear cache")
and the DOM inspector (per default delivered with Cocoon, Tools > Web
Development > DOM Inspector) and of course the JavaScript Console (also
delivered with Cocoon, Tools > Web Development > JavaScript Console).
The also available JavaScript Debugger reached never the status of being
really helpful during our development, but it could have changed in the
meantime.
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [OT?] - XUL
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Joerg Heinicke dijo:
> It's not that difficult, it's "just another markup language".
>
> Not long ago I announced our ConWeb application based on XUL:
> http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=106448993524514&w=2.
> As you can read this is already based on Cocoon
BTW, can you recommend any XUL book? I will like to go a little in depth
with XUL.
Best Regards,
Antonio Gallardo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [OT?] - XUL
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Joerg Heinicke dijo:
> On 30.10.2003 02:09, Antonio Gallardo wrote:
>> Hi:
>>
>> I found this interesting article:
>>
>> http://linuxtoday.com/developer/2003102900426OSHLDV
>>
>> I am wondering if we can provide support for this in Cocoon. As
>> always, comments are very welcomed. :-)
>
> It's not that difficult, it's "just another markup language".
>
> Not long ago I announced our ConWeb application based on XUL:
> http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=106448993524514&w=2.
> As you can read this is already based on Cocoon.
>
> Furthermore I would like to add XUL support to Woody.
This was the idea when I saw the article.
> I only don't know if I have the time to do it in the next weeks while
I'm preparing my diploma thesis.
:-D Good luck and Congrats!
Best Regards,
Antonio Gallardo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [OT?] - XUL
Posted by Alain Javier Guarnieri del Gesu <ja...@ajgdg.com>.
* Joerg Heinicke <jh...@virbus.de> [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 - javi@ajgdg.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [OT?] - XUL
Posted by Joerg Heinicke <jh...@virbus.de>.
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.
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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [OT?] - XUL
Posted by Alain Javier Guarnieri del Gesu <ja...@ajgdg.com>.
* Brent L Johnson <br...@bjohnson.net> [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 - javi@ajgdg.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [OT?] - XUL
Posted by Joerg Heinicke <jh...@virbus.de>.
On 30.10.2003 05:47, Brent L Johnson wrote:
> 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.
I don't know if someone locked this user per accident (3x wrong login)
or someone from our company with intent. I will ask again.
Joerg
>>-----Original Message-----
>>From: Joerg Heinicke [mailto:jheinicke@virbus.de]
>>
>>On 30.10.2003 02:09, Antonio Gallardo wrote:
>>
>>>Hi:
>>>
>>>I found this interesting article:
>>>
>>>http://linuxtoday.com/developer/2003102900426OSHLDV
>>>
>>>I am wondering if we can provide support for this in Cocoon. As
>>>always, comments are very welcomed. :-)
>>
>>It's not that difficult, it's "just another markup language".
>>
>>Not long ago I announced our ConWeb application based on XUL:
>>http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=10644899352
>
> 4514&w=2.
> As you can read this is already based on Cocoon.
>
> Furthermore I would like to add XUL support to Woody. I only don't know
> if I have the time to do it in the next weeks while I'm preparing my
> diploma thesis.
>
> Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: [OT?] - XUL
Posted by Brent L Johnson <br...@bjohnson.net>.
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.
Thanks,
- Brent
> -----Original Message-----
> From: Joerg Heinicke [mailto:jheinicke@virbus.de]
> Sent: Wednesday, October 29, 2003 8:38 PM
> To: users@cocoon.apache.org
> Subject: Re: [OT?] - XUL
>
>
> On 30.10.2003 02:09, Antonio Gallardo wrote:
> > Hi:
> >
> > I found this interesting article:
> >
> > http://linuxtoday.com/developer/2003102900426OSHLDV
> >
> > I am wondering if we can provide support for this in Cocoon. As
> > always, comments are very welcomed. :-)
>
> It's not that difficult, it's "just another markup language".
>
> Not long ago I announced our ConWeb application based on XUL:
> http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=10644899352
4514&w=2.
As you can read this is already based on Cocoon.
Furthermore I would like to add XUL support to Woody. I only don't know
if I have the time to do it in the next weeks while I'm preparing my
diploma thesis.
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [OT?] - XUL
Posted by Joerg Heinicke <jh...@virbus.de>.
On 30.10.2003 02:09, Antonio Gallardo wrote:
> Hi:
>
> I found this interesting article:
>
> http://linuxtoday.com/developer/2003102900426OSHLDV
>
> I am wondering if we can provide support for this in Cocoon. As always,
> comments are very welcomed. :-)
It's not that difficult, it's "just another markup language".
Not long ago I announced our ConWeb application based on XUL:
http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=106448993524514&w=2.
As you can read this is already based on Cocoon.
Furthermore I would like to add XUL support to Woody. I only don't know
if I have the time to do it in the next weeks while I'm preparing my
diploma thesis.
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [OT?] - XUL
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Some older post about XUL in our maillist:
user list:
http://marc.theaimsgroup.com/?l=xml-cocoon-users&w=2&r=1&s=xul&q=b
dev-list:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&w=2&r=1&s=xul&q=b
Best Regards,
Antonio Gallardo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org