I am personally willing to share the code, but I'd have to clear it with my employer. What I did was not super-complicated, and I can summarize it here:
*) I created my own ValidationMetadataProvider class, starting (of course) with the default one. *) I took the approach of mimicking the way that "@ValidateNestedProperties" works - basically, I added code that looked at action bean properties, and when they have a type that's not a plain Java type it calls a (recursive) function that digs through that class and looks for more validation-related annotations. *) I had to cook up a way to "merge" metadata, but that wasn't super-hard; I just build up some intermediate objects, and then populate the real stuff for Stripes. I'd have to look at it again to remember the specifics, but it's not complicated *) I added a "@ValidateFrom" annotaion that allows metadata to be pulled from another class. That's really useful when you've got an action that gathers some parameters, but you don't want to directly hook those to your data objects (ie you don't want Stripersist involved). Thus for like a login "username/password" field, you can pull the metadata from the "security" object (or wherever it is) just by knowing a "beanclass" and a "property" (name). *) I hacked my @ValidateFrom so that in an action, one can use @ValidateFrom to provide an event name for the "on" parameter to @Validate. That's useful in the common case where you've got a single action bean that has both the "launch" and the "save" methods. (Well it's common for me at least.) The business logic objects - sort-of a layer below the action beans themselves - impose the "required" rules, but they don't know anything about action bean event names. Thus in the action bean, a @ValidateFrom annotation tells the mechanism that any "required" rules that don't have their own explicit "on" qualifier should use some particular event name (or list of event names). That way, the validation code doesn't freak out when the "launch" event has no parameters at all. Plus the business logic (also beans, but not Stripes action beans) remains isolated from the Stripes layer. I did most of that stuff while I was still a real newbie to Stripes, and its a testament to the extremely high source code quality that I was able to get it more-or-less working in just a couple days. I've had to tinker with it a couple times (just the other day I finally went back and made my annotation-scrounging code look for annotations on getter/setter methods as well as on Fields) but mostly the basic architecture was very supportive of what I needed to do. If I can share my code, I'll have limited ability to clean it up to public release standards. However, it might be useful for anybody who wants to go off in their own direction. On Fri, Sep 10, 2010 at 4:10 PM, Nikolaos Giannopoulos < nikol...@brightminds.org> wrote: > Mike, > > I agree about pretty much everything you said and am afraid that I will > need to develop this as well as my app has lots of model objects. > > Would you be willing to share the code you developed to extend the > validation? > > Also it might be great to create a JIRA ticket and attach the code for > consideration for integration i.e. so that the Stripes default > validation provider is available alongside your more sophisticated > validation provider OOB and developers could run with one over the other. > > I agree that this is an area of weakness and when one uses JPA you want > to take advantage of those annotations as much as possible otherwise its > a maintenance nightmare. Your thoughts? > > Cheers, > > --Nikolaos > > > > Mike McNally wrote: > > Actually I feel that the basic Stripes mechanisms for annotating > > validation information to be completely inadequate for an application > > of any serious complexity. Inevitably, persisted objects will be > > manipulated by many actions, and the consequent need to repeat the > > validation rules over and over again introduces grave maintenance > > problems. > > > > Thankfully, Stripes is easy to extend, so I (and, I have no doubt, > > many others) extended the validation mechanism as almost the very > > first thing I did with the framework. Specifically what I did was > > replace the default ValidationMetadataProvider so that it follows > > properties and "imports" metadata from their classes. That way, my > > low-level JPA-annotated data objects can include some amount of > > validation metadata, such as field lengths and converter settings. The > > business logic is then (usually) where "required" annotations go. All > > that wraps up to the action bean layer, and since metadata is cached > > at the action bean level it all works out - two different action beans > > referencing the same business logic bean each have their own "mix-in" > > of metadata, and I don't have to repeat validation rules (at least, > > not very often). > > > > It's still not perfect: EL validation isn't really possible because > > the only thing Stripes can bind into the EL context is the action bean > > reference, so EL validation rules from a lower layer can't really work > > because they can't find themselves, so to speak. However I've found > > that it's pretty rare that I need anything that fancy anyway; > > validation is generally either really simple stuff, or else it's > > full-blown code that requires a lot of context. > > > > On Fri, Sep 10, 2010 at 6:40 AM, Richard Hauswald > > <richard.hausw...@googlemail.com > > <mailto:richard.hausw...@googlemail.com>> wrote: > > > > Hi, > > what about creating a Pojo holding all the form variables und > > referencing it in the actionBean and doing validation using > > @ValidateNestedProperties? > > Regards, > > Richard > > > > On Fri, Sep 10, 2010 at 12:52 PM, andres <ispanand...@yahoo.es > > <mailto:ispanand...@yahoo.es>> wrote: > > > > > > What is the best way to separate variabls in a larger form the > > action? In Struts 1 you have a separate action (for the logic) > > and form (to use for fields). In Stripes have all this in > > action. Hope I explained well. > > > > I thought to create a class NameModel with a variabls for a > > form and extend it of BaseActionBean and then extend my > > NombreActionBean class of NameModel to separate variables > > (form fields) from ActionBean and can access to them. And use > > only for the logic NombreActionBean. > > > > Do you know the better way to do it? After picking up the form > > fields NameModel would have to pass them to DAO object to > > store in DB. > > > > Thank you. > > Greetings. > > > > > > > > > ------------------------------------------------------------------------------ > > Automate Storage Tiering Simply > > Optimize IT performance and efficiency through flexible, > powerful, > > automated storage tiering capabilities. View this brief to > > learn how > > you can reduce costs and improve performance. > > http://p.sf.net/sfu/dell-sfdev2dev > > _______________________________________________ > > Stripes-users mailing list > > Stripes-users@lists.sourceforge.net > > <mailto:Stripes-users@lists.sourceforge.net> > > https://lists.sourceforge.net/lists/listinfo/stripes-users > > > > > > > > > > -- > > Richard Hauswald > > Blog: http://tnfstacc.blogspot.com/ > > LinkedIn: http://www.linkedin.com/in/richardhauswald > > Xing: http://www.xing.com/profile/Richard_Hauswald > > > > > ------------------------------------------------------------------------------ > > Automate Storage Tiering Simply > > Optimize IT performance and efficiency through flexible, powerful, > > automated storage tiering capabilities. View this brief to learn how > > you can reduce costs and improve performance. > > http://p.sf.net/sfu/dell-sfdev2dev > > _______________________________________________ > > Stripes-users mailing list > > Stripes-users@lists.sourceforge.net > > <mailto:Stripes-users@lists.sourceforge.net> > > https://lists.sourceforge.net/lists/listinfo/stripes-users > > > > > > > > > > -- > > Turtle, turtle, on the ground, > > Pink and shiny, turn around. > > ------------------------------------------------------------------------ > > > > > ------------------------------------------------------------------------------ > > Automate Storage Tiering Simply > > Optimize IT performance and efficiency through flexible, powerful, > > automated storage tiering capabilities. View this brief to learn how > > you can reduce costs and improve performance. > > http://p.sf.net/sfu/dell-sfdev2dev > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Stripes-users mailing list > > Stripes-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/stripes-users > > > > > -- > Nikolaos Giannopoulos > Director, BrightMinds Software Inc. > e. nikol...@brightminds.org > w. www.brightminds.org > t. 1.613.822.1700 > c. 1.613.797.0036 > f. 1.613.822.1915 > > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Stripes-users mailing list > Stripes-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/stripes-users > -- Turtle, turtle, on the ground, Pink and shiny, turn around.
------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
