Poitras Christian <Christian.Poitras@...> writes: > > Hi, > > As a side note, getters and setters are optional for public attributes. > So this kind of validation will work. > > @Validate(required=true, on="myEvent") > public String myProperty; > // No getter/setter. > > Christian > > -----Message d'origine----- > De : Thomas Menke [mailto:stripesml@...] > Envoyé : August-16-11 5:59 AM > À : Stripes Users List > Objet : Re: [Stripes-users] Cannot get simple validation to work > > On 08/16/2011 05:19 AM, Cefn Hoile wrote: > > Cefn Hoile<tryanotheremail@...> writes: > > > > Once the getters and setters were there everything went swimmingly. This leaves > > a couple of questions in my mind... > > > > 1) Why does the validation reference at... > > http://www.stripesframework.org/display/stripes/Validation+Reference#ValidationR > > eference-AnnotationDrivenValidation > > ...report "The annotations can be attached to either the getter or setter > > methods on the ActionBean. They can also be attached directly to the properties > > (even private ones)." > > > > Perhaps it's implied that getters and setters still need to be there, but the > > annotations can be elsewhere! > > Exactly . > > > > 2) Why does Stripes fail silently in this case. It seems amazing that there > > isn't some part of the code in which a property called design is clearly found > > to be 'missing' from the point of view of Stripes and this should certainly be > > logged rather than swallowed. > > I believe it is logged at the trace level. > I guess it is a design question to just ignore all url-Parameters that > have no use. After all you could still access those parameters using the > context and the servlet request. Or some library (perhaps javascript or > taglib) generates parameters that you simply want to ignore. > > > > > Cefn > > Thomas > > ------------------------------------------------------------------------------ > uberSVN's rich system and user administration capabilities and model > configuration take the hassle out of deploying and managing Subversion and > the tools developers use with it. Learn more about uberSVN and get a free > download at: http://p.sf.net/sfu/wandisco-dev2dev > _______________________________________________ > Stripes-users mailing list > Stripes-users@... > https://lists.sourceforge.net/lists/listinfo/stripes-users > > ------------------------------------------------------------------------------ > uberSVN's rich system and user administration capabilities and model > configuration take the hassle out of deploying and managing Subversion and > the tools developers use with it. Learn more about uberSVN and get a free > download at: http://p.sf.net/sfu/wandisco-dev2dev >
It's fairly obvious I was in error (the word 'Bean' should have given it away). I should know that private fields can only be directly accessed in some fairly narrow circumstances (like aspect weaving) but I've got used to it with JPA enhancers within managed environments, so I didn't keep my eye on the ball. This system is, deliberately, much simpler than a full enterprise stack and that's way better all round. However, whilst I can see there's a good argument for _not_ considering all GET and POST parameters to be owned by Stripes, (on the submission side) I don't see the argument for a tag like <@s.text name="design.featureDesign" /> not to log a severe error when Stripes can't bind the corresponding name while introspecting the ActionBean (on the forms generation side). ------------------------------------------------------------------------------ uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev _______________________________________________ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
