Sylvain Wallez wrote: > > Thanks for reading so far. As I expect this post to generate lots of > discussions, I suggest to create separate threads for particular > subjects (particularily the final "proposals" chapter) in order to keep > the discussion focused. > Now, as we all know this is really a "dangerous" topic as such threads might result in "personal" wars driven by the developers of each part involved. But as Sylvain already pointed out, it's not the reason for this thread to create a "form" war. And personally, I don't think this will happen in Cocoon.
So, I just wanted to throw in my comments as I can only read mails from time to time and can't really participate in the threads. One comment I think that is really import came from my collegue, Guido who said "XForms is a client-side standard", so is it really worth to implement it in the server? (I hope, it's ok to quote you, Guido...don't blame Guido for this comment, just me if required!) I don't know the answer, but if someone would force me to give one, I would tend to say "No". Now, I really never looked at XMLForms or JXForms, but this doesn't say anything about their quality etc, it's simply lack of time. But I looked a little bit at Woody and personally I feel that Woody is really a great approach by separating form definition from the template. Actually, I started to implement the same for my test project, looked at Woody and saw that it already does most of the things I need :) My ideas of building web applications is a little bit different from what we have in Cocoon today: In short, I'm thinking of "writing" (whatever that means) a component for each web page. This component is the controller for that page and connects (MVC) to the model. A template is used to render the page. This template uses bindings to insert data into the template. The bindings are connected to the component which in turn has access to the object model. Simple, or? Example: You have a component EditUser, that has a property user (= method getUser). You have a template (shortened): <form> <input id="surname"/> <input id="forename"/> </form> And the binding <binding id="surname" type="TextInputField"> <value>user.surname</value> </binding> <binding id="forename" type="TextInputField"> <value>user.forename</value> </binding> When the template is processed by the component EditUser, the bindings are evaluated. So e.g. for the input field surname the binding "user.surname" is resolved by invoking "getUser()" on the component and "getSurname()" on the result (JXPath evaluation). When the submitted form data comes to Cocoon again, the EditUser component previously creating the form is the one in charge and delegates to the two input fields. So (without validation) the user is get from the component and setSurname() resp. setForename() is invoked on the user object. The plan is to implement two layers of validation, the first layer in the binding where I can already define obvious validation rules and the second one in the model, because I think there are cases where only the model can validate the date. So perhaps a validateSurname() (if existent) might be invoked on the user. This is more or less my current idea, and I'm trying to find some time to see how this fits into Woody. Now, for this thread, let's not discuss my ideas (I have most of them running already anyway ;) ), this thread has a different topic. Perhaps my idea from above gives some aspects for further discussion on how to do it - if not, just ignore my ideas... Speaking of woody, woody has the template already and the form definiton. Now, what's missing is the binding between the form fields and your business data. But, I think this is realy an important thread for Cocoon. IMHO it doesn't make too much sense to have two (or even more) approaches for the "real form handling in Cocoon" implement at cocoon.apache.org. We should only provide one good and working solution. Other implementations might exist somewhere else, but should not here. So, I think we are on the right track and perhaps combining somehow both approaches into a new (third) one (named XMoody?) is the distant plan. If you read this, you might get the impression that I'm +1 for woody and -1 for XMLForms. But this is not true; I currently only know more about woody than XMLForms and I have a similar idea, so perhaps I'm a little bit to biased... HTH Carsten
