Great! Would be cool if Stripes future implementation of JSR 303 could be used 
as Reference Implementation! This way it will get free publicity across wide 
Java development community!
 
Tim, is there a way that Stripes could be used as RI for JSR 303 (given spec. 
to be implemented)?
 
l8r,
Ruslan

________________________________

From: [EMAIL PROTECTED] on behalf of Aaron Porter
Sent: Wed 13/08/2008 1:21 PM
To: Stripes Users List
Subject: Re: [Stripes-users] reusing validation annotations


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
        
          


<<winmail.dat>>

-------------------------------------------------------------------------
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

Reply via email to