Hi: Comments below.... :)
Carsten Ziegeler dijo: > Validation > ---------- > It's good to have the possibility to define validation in the form and > at the fields. But in some cases your business objects can > validate their values as well and you don't want to code it twice. If we are going to a complete separation of concerns.... The business object has the obligation of validate what it gets. If we see it as a "model" in MVC, then we can use cocoon for view or other framework. A business object cannot relay the validation task to other components. (It only reforce what is told below...) > Simple Example: Imagine you have a user object with an age property > modelled by an int. Now, it's only valid to set an age from 0 to 256. > The business objects should check for valid values. > One possibility > could be by adding a validateAge(int) method to the user object, > so it has three methods setAge, getAge and validateAge (where the > last is optional). This is a good idea, but we must use validateAge() into getAge(). See above... This is what is not clear to me in a OO design. At the end the Age will be validated twice at the view and at the model. :( But maybe this is the price to pay if we go full OO oriented. > So (in conjunction with the binding) the validateAge method could be > invoked to check if the value is valid. This allows validating values > before they are set on the business objects. In case of an validation > error the values should not be set using setAge() etc. Hmm. I am not sure. On one side, the Business model must validate the fields. I agree that the form also had some degree of validation... but sometimes the validation is too complicated (thinking in terms of a form). ie: validating against a database. I know this is not the case you are trying to show, but we will need to take care of when we ask the form for validation and when not. No matter is we have a validateAge() function. Because validateAge() can also be a function to validate the correct age of a person, not only the interval of the value. I am not telling you are wrong, but there is a very thin frontier that is very dificult to define. This is a very interesting point to talk about and we need to define it. On the other side I prefer the approach of defining datatypes for forms. This is more general and allow us to define once a validation rule for a defined datatype in a form. As you wrote above the example of the "age" can be easily handled in the form. Of course in a defined model (application) we can define some rules. ie: The age must be between 0 and 256. The rule validation encapsulated in a datatype allow us to "use" it in any form no matter if the form show a doctor, a patient, a client or a contact. All this entities has someone in common a validation rule for datatype called "age". > Now, this is one idea I have. The other one deals with validation on > complete business objects where perhaps one property depends on > another. In this case, the form handling framework could start a > "transaction". I dont think this type of validation can be delegated to a form. For me this type of validation is a model issue, not a view issue. Also, in the web manage transactions is a very resource consuming task (memory). Think in an attack that create too many "transactions" and never ends it. This is the problem I see. Maybe this can be also an environment with too many users. > It first fetches all old values of the business objects, > sets the new values and invokes the validation (validate() method > on the business object?). When the validation is ok, the > transaction is finished. Too risky. We will need to create a "manager" that take care of that. If we have more than 2 open transactions there is always a posibility to changes the data just before Cocoon send the form to the user. This is why the model must validate always what it gets. > If the validation fails, the transaction > is rolled back and the old values are restored. > > These are only some thoughts, but for me the most important part > is the binding and the interaction between the form handling and > the business model. I think the answer is at the flow controller level. Your ideas looks great, but it start mixing model and view in some way. And I think this is exactly what we are trying to avoid. :( Thanks for the ideas, I know this is a very "hairy problem". :) Many of us are trying to find the right way in this stuff and of course all the comments are welcome :) Best Regards, Antonio Gallardo
