cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <>
Subject Re: [RT] - XUL revisited....
Date Tue, 06 Apr 2004 14:21:42 GMT
On Tue, 2004-04-06 at 16:01, Antonio Gallardo wrote:
> Bruno Dumon dijo:
> > I'm wondering though what the value of this is.
> >
> > The main advantage of CForms is to handle the typical problem of HTML
> > forms: the form needs to be redisplayed in a loop until everything's
> > valid. This is because the browser is a stupid client which we need to
> > send a new page after each interaction.
> >
> > If you're developing a smarter client using XUL or Flash, you're not
> > likely going to send a new XUL file or Flash movie to the browser
> > between each interaction. Rather, all validation logic (and event
> > handling logic) can be implemented in the client, which can communicate
> > XML messages with the server. Somehow forcing CForms in between there
> > seems unnatural to me.
> (WARNING: Antonio is in no way a XUL guru):

me neither ;-)

> Two things:
> 1-XUL can be used also as a HTML++?

Yep, though in that case I wonder if the XUL advantage is big enough to
bind you to one browser?

> 2-We have place for YEFF (Yet another form framework) in Cocoon with
> enhanced XUL controls?

nope, but the way I was thinking it wouldn't be needed. The XUL-client
would rather call web services. Those in itself could be implemented
based on CForms handling. I was just wondering if this would make sense,
and I'm not sure yet. As always, probably depends on the application.

> What I see is people asking for a test drive in XUL. And until we don't
> provide it, here will be over and over more XUL threads. :-D

Sure, I'm not against this. I'm also interested to see what would come
out of this. What I was writing was just a thought.

Bruno Dumon                   
Outerthought - Open Source, Java & XML Competence Support Center                

View raw message