Bertrand Delacretaz dijo: > Le 6 avr. 04, à 14:49, Bruno Dumon a écrit : > >> 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.
Hmm..... First rule: "Never trust the client". In order to apply this rule, we need to validate the request on the server. CForms still are useful here. If not good validated return it back to the client. > 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? +1 >> ...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. +1 Best Regards, Antonio Gallardo
