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...
Right. With XUL the loop is gone.
But CForms is not only about the validation loop: if a new mechanism is created to use XUL clients, why not base the forms definitions on the existing model/widget/template stuff?
...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...
I think the CForms validation framework can still be useful for validation that one does not want to implement on the client.
So, correct me if I'm wrong, but the only part of CForms that is not used in an XUL client scenario is the form loop mechanism. I think it makes sense to base XUL stuff on the existing framework wherever possible, rather than reinventing the wheel.
-Bertrand
