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
