Just to add a little more to this thread (sorry, I haven't been
reading my list mail for a few days, too much going on). I think
Gregg got my position only half right ;) My view on this kinda stuff
is pretty straightforward:
- True invariants should be expressed in the domain model. Stuff
like "a user should always have a username"
- Contextual validation/constraints should be expressed where the
context exists. I.e. in an ActionBean, a web service end point etc.
Depending on the kind of application you are writing you might end up
with a split approaching 90%/10% or the other way around!
I hadn't really given much thought to being able to embed Stripes
validation annotations in nested objects because most people react
pretty violently to the idea of pushing annotations from a web
framework down into their domain model. But this actually could be a
win. If we allowed this (and pushed the right approach) you could
use this to create re-usable form objects as/when needed to share
validation code across ActionBeans.
Ultimately my hope is that with JSR-303 we'll define a set of
validations that everyone is happy to use in their model classes and
then Stripes will support JSR-303 in the model classes and Stripes
validations in the ActionBeans.
-t
On Aug 18, 2008, at 1:21 PM, Chris Herron wrote:
One of the unfortunate things about JSR-303 as it currently stands
is that it doesn't allow you to define validation rules for nested
properties. Instead you're supposed to define validation "groups"
within your domain objects. This means your domain layer has to
know about every context in which it will be used. I asked Emmanuel
Bernard (the JSR-303 spec lead) about his last week. For those of
you interested, the discussion thread is here:
JSR-303 Contextual Validation?
Chris.
On Aug 13, 2008, at 1:41 PM, Aaron Porter wrote:
Yes, JSR 303 is for annotating the domain classes.
I think we'll probably end up with several validation options that
will include the current method of annotating ActionBeans, JPA
annotations, Hibernate annotations, and JSR 303. All of these
could be used simultaneously.
Aaron
Gregg Bolinger wrote:
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
---------------------------------------------------------------------
----
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
