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 http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
