> This has been talked about before on this mailing list and on IRC. The > problem is that there are 2 different thoughts on where validation > should be defined; in the controller or in the model. I don't believe > anyone is right or wrong. Tim believes it belongs in the controller > which is why its done the way it is. So there is that.
Thanks for the context Gregg. It's great to hear this stuff has been discussed, but a shame to hear it's kind of stalemated. I can understand the tension between model vs controller as the most appropriate place for validation logic - my own gut feeling is that sometimes it's genuinely going to be one and sometimes the other. However to look at the problem a different way, I don't see delegating annotations to aggregated objects as necessarily moving validation logic "out of the controller" - it's the developer's choice whether those objects are purely front end constructs or whether they are actually model objects. The overriding point is more about maintainability and keeping things DRY - even if you are only talking about your front end controller code, this becomes important in a complex app. > I agree that reusing validation logic would be a really cool thing for > Stripes but no one has been able to come up with a good solution though > we've tried. Would love to hear thoughts & comments of others. Cheers & thanks, Simon. 8<---- snip ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Stripes-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/stripes-users
