I haven't read the proposal but doesn't that force the meta data into the domain layer?
Gregg Aaron Porter wrote: > We're probably going to try to make the validation system pluggable > and add support for JSR 303 http://jcp.org/en/jsr/detail?id=303. After > all, Tim is in the Expert Group. :-) > > Aaron > > Gregg Bolinger wrote: >> I think our limitations on how to proceed might have more to do with >> Java than the framework. By that I mean other languages, like python, >> can make these types of things more transparent because of the nature of >> the language. >> >> I think, rather than looking at django, grails, etc, we might have >> better luck looking at how frameworks like Spring, Struts2, etc handle >> this and see how we can work what they do into Stripes, the Stripes way, >> of course. >> >> Gregg >> >> Xavier Morel wrote: >> >>> Simon wrote: >>> > my own gut feeling is that sometimes it's genuinely going to be one >>> and sometimes the other. >>> >>> That's also what i believe. Which is why the validation system should be >>> orthogonal to the rest of the framework, and should be usable in both >>> situations . >>> >>> >>> >>>> Would love to hear thoughts & comments of others. >>>> >>>> >>>> >>> For what it's worth, i think Django has the right approach here: >>> explicit binding and validation with specific "form" objects used for >>> that part. This gives great flexibility because: >>> >>> * Since binding and validation are explicit, the user is not bound to a >>> specific validation workflow (something I found annoying with Stripes) >>> * Forms (bindings and validation) are not bound to a given action/view, >>> allowing their trivial reuse (without the need for complex inheritance >>> hierarchies which don't make sense either architecturally or at the >>> business level) limiting duplication >>> * Since binding is explicit, there is no limitation to a single form per >>> action/view, it's possible to use several forms acting as subforms >>> (making reuse easier, especially when coupled with the previous point). >>> Django also makes it trivially easy to use a given form several times >>> (using a prefix system in HTML controls for data dispatching) >>> * And validation is not bound to a specific part of the workflow, >>> django's forms don't depend on anything (almost) which means they're >>> really general-purpose data validation mechanisms, even if strongly >>> slanted towards validating HTTP requests (see their widgets system), as >>> long as something can be coerced into a python dict (a Java map) it can >>> be validated. >>> >>> Finally, because validation becomes very decoupled with the rest of the >>> framework, it's possible to modularize it and reuse it from project to >>> project, or ship validator objects with other modules without >>> constraining the controller workflow (e.g. if you're shipping a module >>> that consists of a few models and DAOs, you can also ship validator >>> classes but you still let the programmers integrate that the way they >>> want in their projects) >>> >>> Xavier >>> >>> >>> ------------------------------------------------------------------------- >>> 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 >>> >>> >> >> >> ------------------------------------------------------------------------- >> 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 >> >> > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > 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 > ------------------------------------------------------------------------- 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
