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
