tag:blogger.com,1999:blog-6178209.post113393768462707703..comments2007-04-16T05:50:18.537-05:00Igorhttp://www.blogger.com/profile/12832903167357753682noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-6178209.post-1134059616194902162005-12-08T10:33:00.000-06:002005-12-08T10:33:00.000-06:00I think the trick is to have the validation <B>rules</B> in the domain model, but have the validation applied in the view and the controller, such that users can get instant feedback as they type into a form, and that controllers can call the validation code and redirect people to the appropriate location when validation fails.<BR/><BR/>In Struts, I always had the Struts Validation delegate to the domain objects at the controller level, but it was difficult for this to flow all of the way down to the html form.Matt Mhttp://www.blogger.com/profile/16098483018096096360noreply@blogger.comtag:blogger.com,1999:blog-6178209.post-1133971487405771302005-12-07T10:04:00.000-06:002005-12-07T10:04:00.000-06:00I had a similar epiphany coming from ASP.Net. ASP.Net has some nice validation server controls for the views that are <I>very</I> tempting to use.<BR/><BR/>Seeing how Rails puts that logic in the model makes a lot more sense. You can now reuse your validations everywhere the model is just used, not just the one or two forms it's a part of. <BR/><BR/>Regarding comment #1: there's isn't much sharing of domain objects across projects in ruby on rails. Each project has its own domain models with their own validations and other business rules. Common logic can easily be refactored out into acts_as_* plugins or mixins as well.Rickhttp://techno-weenie.netnoreply@blogger.comtag:blogger.com,1999:blog-6178209.post-1133969953475904852005-12-07T09:39:00.000-06:002005-12-07T09:39:00.000-06:00Developer seeking guidance or ideas.<BR/><BR/>I subscribe to the view that validation should belong to domain objects like you described. It is more like my domain objects always say they are responsible for validating and making sure data is correct. But the issue I have with this approach is often some of my domain objects will be used across different projects and business rules vary based on the context. Can you suggest a clean approach how to handle this?<BR/><BR/>Thanks!Anonymousnoreply@blogger.com