Re: XULifying CForms (yet another attempt?)
On 10/10/05, Stefano Mazzocchi [EMAIL PROTECTED] wrote: I've been working heavily with XUL recently and I have to say, it could be a refreshing experience if you were used to build DHTML applications. At the same time, be aware that XUL is normally used inside the mozilla security sandbox (say, loaded with chrome:// instead of being loaded with http:// or file://), things change rather dramatically when you use remote XUL (as it is called when you load XUL from http:// as opposed to local XUL. From what I reckon, the security sandbox shouldn't be that much of an issue when dealing just with forms with no access to local resources. Things of course would change when it comest to mangling with the user's station, such as writing files or opening socket connections to different hosts, but it shouldn't be different from applets, to say the least. As far as XBL goes, I would suggest to start without and see how far you can keep going without it (which, for me, is pretty far since I'm not developing reusable UI widgets) Then again, a good lot of CForms is about reusable UI widgets, which makes me think that we'll need XBL pretty soon. Is there a reason to be scared though? I don't quite find XBL, in its simplest incarnations, a daunting technology: if you use it as a poor's man XSLT/macro processor it's more or less a piece of cake. I agree, though, on staying away from overcomplication as much as we can. As for as XHTML, XUL does *NOT* replace XHTML, in fact, you can consider it as an extension to it. There are things that are, IMO, but better than in XHTML (the vbox/hbox/flex model, for example, *WAY* better than the stinking table/tr/td or even better than the CSS3 column layouts) but some XUL widgets are nothing but reusable XHTML constructs with embedded style and behavior (and that's why XBL is related to CSS, you can think if XBL as an extension to CSS to make behavior portable and isolated.. too bad they got the syntax wrong, the use of the XML for XBL is a total golden hammer instance if you ask me) rant Now, call me an old fart, but I don't quite like the continuous and oh-so-fashionable XML bashing I see nowadays. Clearly, writing angle brackets all over the place isn't the most comfortable way of working, but as long as I will be able to (per)use transformations so that I will be able to generate an application using just an XSL stylesheet from a model, I'll be an happy puppy. I just wish we had a (successful) alternate syntax to avoid the carpal tunnel syndrome, yet XSLT/XPath/validations and friends are just too powerful technologies that make me easily fogive input verbosity. /rant As far as roundtripping, Ajax all over the place is the only reasonable answer, IMO... be aware that this makes browser history and bookmarking an interesting problem. Yup, my point exactly. One of the first problems to dissect is how CForms can go from a navigation based framework to a real GUI, where navigation happens locally and it's calculated (mostly) on the client. This is my first and foremost concern and at times I have the feeling that Xul in CForms will have to remain a pure translation of html interfaces (as in s/\.html/\.xul/g). Not a big deal after all. At the same time, browsers are *NOT* build with that in mind and remote XUL cannot prevent the users from clicking the back button Well, this is where continuation should help us. At least possibly. :-) Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: XULifying CForms (yet another attempt?)
Gianugo Rabellino gianugo at gmail.com writes: 1. server roundtrip model: Xul doesn't really fit in a request-response model where all data travel at once upon hitting a submit button. This might lead to two different alternatives: (a) ajax all over the place, where more or less every widget submits events to a Cocoon server or (b) server roundtrips being avoided whenever possible thanks to the richest functionalities of a Xul frontend (think repeaters). Is it an either-or-decision? Well, the way I see it is that either the Xul incarnation of CForms provides a different roundtrip model for client-server communication or it would just be a 1:1 mapping to the current HTML forms. Not much added value compared to an HTML rendering, given it would still be browser based *and* strongly tied to just one browser. Why should anyone choose to use the Xul version nowadays then? I think it's clear using XUL the HTML-way makes no sense. My either-or was related to the two mentioned alternatives. And these two depend heavily on the widget IMO. Convergence with the new Ajax model of CForms somewhat blurs the line, yet I feel that a mere translation of CForms widgets to Xul without a rethink of the roundtrip model might be somewhat limiting (as in uh, ok, so what?). Actually, I might go as far as saying that the whole Xul/CForms marriage might not have that much sense now that we have Ajax and all the Web 2.0 yadda-yadda. That is, unless we figure out some real advantage in server interaction. Claas and I came to the conclusion that Ajax as-is does not work with XUL. If you mean as-is as the current Cocoon incarnation, I don't quite see why, apart from some tweaks that might be necessary. The whole idea of Ajax actually was in Xul since day one, given that manipulation of the widget tree is delegated to javascript and network communication has to happen through XmlHttpRequest. And I have the perception that XBL might play a role even here I meant the browser update instructions which is actually only a client-side replacement of elements. The idea of rich clients includes the move of the view to the client, which does not happen with the current Ajax stuff. Only data should be sent to the client. This is what the RDF and XUL template stuff is about. My first idea was to provide one CForms template which knows how to display all the widgets described in the RDF, which means the RDF has to include information about the view (e.g. radio buttons vs. drop-down list). Besides this disadvantage Claas mentioned it is impossible to match all and everything in my super CForms template. So we switched to the approach I attached to the bug. Clean separation of data and view (form instance markup is generated with the FormsGenerator, so it contains no details about the view). The template is only on the client, but form-specific. That's what form1_template.xul is for example. Unfortunately this approach seems to be horrible to template writers. If you have to learn the concepts of RDF and this horrible templates of XUL before getting something to work ... Our conclusion: it's neither the correct approach. Now Claas tries something else on the client-side which is more or less a replacement for XUL templates: DOM 3 XPath or XSLT. The XPath approach would only work for Gecko engine at the moment, but maybe also in future IEs. It's similar to XUL template in that extent that it tries to match on elements and creates some markup if an XPath matches. XSLT should work even now in nearly all browsers. This is more or less the move of the stylesheets currently on the server to the client. Hmm... point is I'm afraid you won't go much farther than a few text input, checkboxes, radios and selection lists without XBL... You can get really far without XBL. By the way, the other part of a client-server-roundtrip, sending a request, is quite easy. Just walking through the DOM, collecting all form elements and constructing a request is easy. Jörg
Re: XULifying CForms (yet another attempt?)
On 10/11/05, Joerg Heinicke [EMAIL PROTECTED] wrote: Gianugo Rabellino gianugo at gmail.com writes: 1. server roundtrip model: Xul doesn't really fit in a request-response model where all data travel at once upon hitting a submit button. This might lead to two different alternatives: (a) ajax all over the place, where more or less every widget submits events to a Cocoon server or (b) server roundtrips being avoided whenever possible thanks to the richest functionalities of a Xul frontend (think repeaters). Is it an either-or-decision? Well, the way I see it is that either the Xul incarnation of CForms provides a different roundtrip model for client-server communication or it would just be a 1:1 mapping to the current HTML forms. Not much added value compared to an HTML rendering, given it would still be browser based *and* strongly tied to just one browser. Why should anyone choose to use the Xul version nowadays then? I think it's clear using XUL the HTML-way makes no sense. My either-or was related to the two mentioned alternatives. And these two depend heavily on the widget IMO. I see your point. Problem is whether the CForms approach can be abstracted so that a CForm can be transparently rendered both as HTML or as XUL, something I don't see likely to happen at the moment. Consider repeaters in a non-Ajax scenario (i.e. no ajax=true): the HTML CForm will need a roundtrip to the server, which would be overkill for the more powerful XUL rendering. Convergence with the new Ajax model of CForms somewhat blurs the line, yet I feel that a mere translation of CForms widgets to Xul without a rethink of the roundtrip model might be somewhat limiting (as in uh, ok, so what?). Actually, I might go as far as saying that the whole Xul/CForms marriage might not have that much sense now that we have Ajax and all the Web 2.0 yadda-yadda. That is, unless we figure out some real advantage in server interaction. Claas and I came to the conclusion that Ajax as-is does not work with XUL. If you mean as-is as the current Cocoon incarnation, I don't quite see why, apart from some tweaks that might be necessary. The whole idea of Ajax actually was in Xul since day one, given that manipulation of the widget tree is delegated to javascript and network communication has to happen through XmlHttpRequest. And I have the perception that XBL might play a role even here I meant the browser update instructions which is actually only a client-side replacement of elements. The idea of rich clients includes the move of the view to the client, which does not happen with the current Ajax stuff. Only data should be sent to the client. This is what the RDF and XUL template stuff is about. Well, definitely the ideal scenario would be the (rich) client handling navigation and posting pure data back and forth (either bound or unbound to the underlying model - better, the underlying model's XML view, even for objects). Then again, however, this would stretch the CForm paradigm quite a bit. Not sure it's feasible without a major impact in CForms as a whole. My first idea was to provide one CForms template which knows how to display all the widgets described in the RDF, which means the RDF has to include information about the view (e.g. radio buttons vs. drop-down list). Besides this disadvantage Claas mentioned it is impossible to match all and everything in my super CForms template. So we switched to the approach I attached to the bug. Clean separation of data and view (form instance markup is generated with the FormsGenerator, so it contains no details about the view). The template is only on the client, but form-specific. That's what form1_template.xul is for example. Unfortunately this approach seems to be horrible to template writers. If you have to learn the concepts of RDF and this horrible templates of XUL before getting something to work ... Well, I have been tempted by XUL templates, then took some time to read a few rants here and there and became convinced that it's not that mature and reliable as a technology (see http://www.jerf.org/resources/xblinjs/whyNotMozilla/notXulTemplates.html). I know I keep pestering with XBL, but I have the gut feeling that XBL won't be as difficult as Xul templates and could provide a much better experience for form template writers. But I really need to get my feet wet and provide some code. Our conclusion: it's neither the correct approach. Now Claas tries something else on the client-side which is more or less a replacement for XUL templates: DOM 3 XPath or XSLT. The XPath approach would only work for Gecko engine at the moment, but maybe also in future IEs. Uhm, so what? Aren't we targetting XUL in Gecko? It's similar to XUL template in that extent that it tries to match on elements and creates some markup if an XPath matches. Yup, document.evaluate()
Re: XULifying CForms (yet another attempt?)
Gianugo Rabellino wrote: On 10/10/05, Stefano Mazzocchi [EMAIL PROTECTED] wrote: I've been working heavily with XUL recently and I have to say, it could be a refreshing experience if you were used to build DHTML applications. At the same time, be aware that XUL is normally used inside the mozilla security sandbox (say, loaded with chrome:// instead of being loaded with http:// or file://), things change rather dramatically when you use remote XUL (as it is called when you load XUL from http:// as opposed to local XUL. From what I reckon, the security sandbox shouldn't be that much of an issue when dealing just with forms with no access to local resources. Things of course would change when it comest to mangling with the user's station, such as writing files or opening socket connections to different hosts, but it shouldn't be different from applets, to say the least. That is the theory. In practice, I heard it's a lot more painful, due to bugs and overconcerned security restrictions. As far as XBL goes, I would suggest to start without and see how far you can keep going without it (which, for me, is pretty far since I'm not developing reusable UI widgets) Then again, a good lot of CForms is about reusable UI widgets, which makes me think that we'll need XBL pretty soon. Is there a reason to be scared though? I don't quite find XBL, in its simplest incarnations, a daunting technology: if you use it as a poor's man XSLT/macro processor it's more or less a piece of cake. I agree, though, on staying away from overcomplication as much as we can. Oh, no, nothing to be really scared off. Just a way to reduce the barrier of entry... but if you think you need it, go for it. As for as XHTML, XUL does *NOT* replace XHTML, in fact, you can consider it as an extension to it. There are things that are, IMO, but better than in XHTML (the vbox/hbox/flex model, for example, *WAY* better than the stinking table/tr/td or even better than the CSS3 column layouts) but some XUL widgets are nothing but reusable XHTML constructs with embedded style and behavior (and that's why XBL is related to CSS, you can think if XBL as an extension to CSS to make behavior portable and isolated.. too bad they got the syntax wrong, the use of the XML for XBL is a total golden hammer instance if you ask me) rant Now, call me an old fart, but I don't quite like the continuous and oh-so-fashionable XML bashing I see nowadays. Clearly, writing angle brackets all over the place isn't the most comfortable way of working, but as long as I will be able to (per)use transformations so that I will be able to generate an application using just an XSL stylesheet from a model, I'll be an happy puppy. I just wish we had a (successful) alternate syntax to avoid the carpal tunnel syndrome, yet XSLT/XPath/validations and friends are just too powerful technologies that make me easily fogive input verbosity. /rant all right, all right. look, it can be worse, I work with people that want everything to be RDF ;-) As far as roundtripping, Ajax all over the place is the only reasonable answer, IMO... be aware that this makes browser history and bookmarking an interesting problem. Yup, my point exactly. One of the first problems to dissect is how CForms can go from a navigation based framework to a real GUI, where navigation happens locally and it's calculated (mostly) on the client. This is my first and foremost concern and at times I have the feeling that Xul in CForms will have to remain a pure translation of html interfaces (as in s/\.html/\.xul/g). Not a big deal after all. Would be nice to work with other types of interaction too, though, like wizards and decks, but that's another story. At the same time, browsers are *NOT* build with that in mind and remote XUL cannot prevent the users from clicking the back button Well, this is where continuation should help us. At least possibly. :-) Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/) -- Stefano.
Re: XULifying CForms (yet another attempt?)
On 10/11/05, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Gianugo Rabellino wrote: snip/ rant Now, call me an old fart, but I don't quite like the continuous and oh-so-fashionable XML bashing I see nowadays. Clearly, writing angle brackets all over the place isn't the most comfortable way of working, but as long as I will be able to (per)use transformations so that I will be able to generate an application using just an XSL stylesheet from a model, I'll be an happy puppy. I just wish we had a (successful) alternate syntax to avoid the carpal tunnel syndrome, yet XSLT/XPath/validations and friends are just too powerful technologies that make me easily fogive input verbosity. /rant all right, all right. look, it can be worse, I work with people that want everything to be RDF ;-) Oh dear, you have my sympathies. Back when RDF/XML was still a candidate spec. we had a business partner that insisted on using it. Must have at least doubled the size and complexity of the project snip/ -- Peter Hunsberger
Re: XULifying CForms (yet another attempt?)
Gianugo Rabellino gianugo at gmail.com writes: I think it's clear using XUL the HTML-way makes no sense. My either-or was related to the two mentioned alternatives. And these two depend heavily on the widget IMO. I see your point. Problem is whether the CForms approach can be abstracted so that a CForm can be transparently rendered both as HTML or as XUL, something I don't see likely to happen at the moment. Consider repeaters in a non-Ajax scenario (i.e. no ajax=true): the HTML CForm will need a roundtrip to the server, which would be overkill for the more powerful XUL rendering. I don't think so. That was also the reason why I care about cross-browser compatibility. Read below. Well, definitely the ideal scenario would be the (rich) client handling navigation and posting pure data back and forth (either bound or unbound to the underlying model - better, the underlying model's XML view, even for objects). Then again, however, this would stretch the CForm paradigm quite a bit. Not sure it's feasible without a major impact in CForms as a whole. Why? You just have to move the template part to the client. This means more or less just dumping fi markup. There might be needed some adaptions, but the general concept should work with CForms as-is. I know I keep pestering with XBL, but I have the gut feeling that XBL won't be as difficult as Xul templates and could provide a much better experience for form template writers. But I really need to get my feet wet and provide some code. Maybe you already have a concept and can explain it a bit more. My problem is I don't see how XBL can be used as template language - especially when it gets to more complex widgets like trees or repeaters. Again, why are you worried about cross-browser compliance? Why not? Would it not be better to support a common rich-client style of CForms that supports multiple browsers? This moves the complete view handling to the client for the Ajax stuff. The concept can work for both XUL and HTML. By the way, the other part of a client-server-roundtrip, sending a request, is quite easy. Just walking through the DOM, collecting all form elements and constructing a request is easy. Easy? Yes. Clean? Not so sure... voices in my head keep whispering use XML flying back and forth instead than plain constructed request parameters. Having CForms capable to deal with forms posted as XML would have the great bonus of being able to interact with XForms on the client side, which, hey, would not be that bad! Of course. For the first step we just decided to stay with the request parameters as it would not need any adaptions on the server side. Jörg
Re: XULifying CForms (yet another attempt?)
Gianugo Rabellino gianugo at gmail.com writes: I'm more and more inclined in devoting some of my Copious Free Time to a Xul CForms renderer, and I wanted to catch up with other fellow members and see what's going on. That was what Claas Thiele and I started at the hackathon. I understand from http://issues.apache.org/bugzilla/show_bug.cgi?id=25295 that Jorg is already doing something, so before reinventing wheels I'd love to know what the current status is and if/how I might help. Claas has the code and will send it to me probably today. After this I will attach it to the bug and go into the details. 1. server roundtrip model: Xul doesn't really fit in a request-response model where all data travel at once upon hitting a submit button. This might lead to two different alternatives: (a) ajax all over the place, where more or less every widget submits events to a Cocoon server or (b) server roundtrips being avoided whenever possible thanks to the richest functionalities of a Xul frontend (think repeaters). Is it an either-or-decision? Convergence with the new Ajax model of CForms somewhat blurs the line, yet I feel that a mere translation of CForms widgets to Xul without a rethink of the roundtrip model might be somewhat limiting (as in uh, ok, so what?). Actually, I might go as far as saying that the whole Xul/CForms marriage might not have that much sense now that we have Ajax and all the Web 2.0 yadda-yadda. That is, unless we figure out some real advantage in server interaction. Claas and I came to the conclusion that Ajax as-is does not work with XUL. 2. the role of XBL. I feel XBL (xul binding/extension language) might play an important role in producing advanced widgets (again, think repeaters, calendar popups, double selection lists... well, you name it). Still, XBL is tightly coupled with CSS, and I'm not sure how to manage the CSS-XBL relationship within Cocoon. That's really advanced stuff. Starting with simple stuff will be hard enough ;) Well, these are just a few initial thoughts, which don't even deserve the status of [RT]: let's say I'm just trying to break the ice and see what's going on in Xul/Cocoonland. Awaiting for your comments! Breaking the ice might be necessary :) Wait for the code submit and the status I will send. Jörg
Re: XULifying CForms (yet another attempt?)
On 10/10/05, Joerg Heinicke [EMAIL PROTECTED] wrote: Gianugo Rabellino gianugo at gmail.com writes: 1. server roundtrip model: Xul doesn't really fit in a request-response model where all data travel at once upon hitting a submit button. This might lead to two different alternatives: (a) ajax all over the place, where more or less every widget submits events to a Cocoon server or (b) server roundtrips being avoided whenever possible thanks to the richest functionalities of a Xul frontend (think repeaters). Is it an either-or-decision? Well, the way I see it is that either the Xul incarnation of CForms provides a different roundtrip model for client-server communication or it would just be a 1:1 mapping to the current HTML forms. Not much added value compared to an HTML rendering, given it would still be browser based *and* strongly tied to just one browser. Why should anyone choose to use the Xul version nowadays then? Convergence with the new Ajax model of CForms somewhat blurs the line, yet I feel that a mere translation of CForms widgets to Xul without a rethink of the roundtrip model might be somewhat limiting (as in uh, ok, so what?). Actually, I might go as far as saying that the whole Xul/CForms marriage might not have that much sense now that we have Ajax and all the Web 2.0 yadda-yadda. That is, unless we figure out some real advantage in server interaction. Claas and I came to the conclusion that Ajax as-is does not work with XUL. If you mean as-is as the current Cocoon incarnation, I don't quite see why, apart from some tweaks that might be necessary. The whole idea of Ajax actually was in Xul since day one, given that manipulation of the widget tree is delegated to javascript and network communication has to happen through XmlHttpRequest. And I have the perception that XBL might play a role even here 2. the role of XBL. I feel XBL (xul binding/extension language) might play an important role in producing advanced widgets (again, think repeaters, calendar popups, double selection lists... well, you name it). Still, XBL is tightly coupled with CSS, and I'm not sure how to manage the CSS-XBL relationship within Cocoon. That's really advanced stuff. Starting with simple stuff will be hard enough ;) Hmm... point is I'm afraid you won't go much farther than a few text input, checkboxes, radios and selection lists without XBL... Breaking the ice might be necessary :) Wait for the code submit and the status I will send. Sure thing, looking forward to it! -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: XULifying CForms (yet another attempt?)
Gianugo Rabellino wrote: I've been playing quite a bit these days with Xul, after a few years' hyatus which made me appreciate the comeback even more. :) I'm more and more inclined in devoting some of my Copious Free Time to a Xul CForms renderer, and I wanted to catch up with other fellow members and see what's going on. I understand from http://issues.apache.org/bugzilla/show_bug.cgi?id=25295 that Jorg is already doing something, so before reinventing wheels I'd love to know what the current status is and if/how I might help. So far, I have identified a few points on my radar: 1. server roundtrip model: Xul doesn't really fit in a request-response model where all data travel at once upon hitting a submit button. This might lead to two different alternatives: (a) ajax all over the place, where more or less every widget submits events to a Cocoon server or (b) server roundtrips being avoided whenever possible thanks to the richest functionalities of a Xul frontend (think repeaters). Convergence with the new Ajax model of CForms somewhat blurs the line, yet I feel that a mere translation of CForms widgets to Xul without a rethink of the roundtrip model might be somewhat limiting (as in uh, ok, so what?). Actually, I might go as far as saying that the whole Xul/CForms marriage might not have that much sense now that we have Ajax and all the Web 2.0 yadda-yadda. That is, unless we figure out some real advantage in server interaction. 2. the role of XBL. I feel XBL (xul binding/extension language) might play an important role in producing advanced widgets (again, think repeaters, calendar popups, double selection lists... well, you name it). Still, XBL is tightly coupled with CSS, and I'm not sure how to manage the CSS-XBL relationship within Cocoon. 3. HTML orientation of CForms: despite a clear intention to stay as neutral as possibile, CForms has a strong bias towards HTML in its most advanced widgets (well, think HTMLarea to see my point). I'm not sure if it's entirely possible to get rid of the HTML heritage, and I kinda feel that in some cases it even doesn't make much sense (hey, after all Xul is happy with xhtml snippets). Well, these are just a few initial thoughts, which don't even deserve the status of [RT]: let's say I'm just trying to break the ice and see what's going on in Xul/Cocoonland. Awaiting for your comments! I've been working heavily with XUL recently and I have to say, it could be a refreshing experience if you were used to build DHTML applications. At the same time, be aware that XUL is normally used inside the mozilla security sandbox (say, loaded with chrome:// instead of being loaded with http:// or file://), things change rather dramatically when you use remote XUL (as it is called when you load XUL from http:// as opposed to local XUL. Not many people publish their content directly in XUL not even the most advanced web mails publish their content in XUL. In theory, there is no reason why a web mail should not look and feel *EXACTLY* like thunderbird... but it never happened and I suspect not for lack of trying but for bugs or architectural limitations. So, be aware that weird behavior might be due to that. (a way to know for sure is to load your xul directly from chrome:// or by passing it as a parameter to the moz command line) As far as XBL goes, I would suggest to start without and see how far you can keep going without it (which, for me, is pretty far since I'm not developing reusable UI widgets) As for as XHTML, XUL does *NOT* replace XHTML, in fact, you can consider it as an extension to it. There are things that are, IMO, but better than in XHTML (the vbox/hbox/flex model, for example, *WAY* better than the stinking table/tr/td or even better than the CSS3 column layouts) but some XUL widgets are nothing but reusable XHTML constructs with embedded style and behavior (and that's why XBL is related to CSS, you can think if XBL as an extension to CSS to make behavior portable and isolated.. too bad they got the syntax wrong, the use of the XML for XBL is a total golden hammer instance if you ask me) As far as roundtripping, Ajax all over the place is the only reasonable answer, IMO... be aware that this makes browser history and bookmarking an interesting problem. XUL is not going to change the way you interact with the server if not to make it more obvious that there is no need to refresh a page if the content changing is just marginal and there is no need to bookmark. At the same time, browsers are *NOT* build with that in mind and remote XUL cannot prevent the users from clicking the back button (and I'm not sure if moz itself keeps the state in the remote xul fields... but I see no reason why it shouldn't, being form fields in XUL the same XHTML dom elements, just wrapped with more style and behavior) Anyway, using XHTML/XUL multichanneling for CForms would indeed be nice. -- Stefano.
