Mike, Thanks for the summary. Much appreciated. I understand your needed to clear a request like this with your employer.
I guess my point was that this is one area that Stripes could use some improvement and although it isn't complicated everyone needs to build their own solution / implementation, test, and debug resulting in duplication of effort over and over again. For example Simon provided: http://www.badboy.com.au/stripes/import.html Then Dan provided the code snippets in the thread for "JSR 303 validation integration with Stripes" If you were able to share the code then what I would commit to is taking the best of what your code offers, the nested support that Simon's code offers (we have lots of embedded objects and I'm not sure whether or not your code drills down into them...) and whatever other enhancements we can add and then put the code back in the hands of the community via either a JIRA ticket submission and / or a blog write up attributing the parties that provided the code or whatever other license / copyright is provided. Which hopefully results in a win-win for all and hopefully results in some code enhancements / improvements for you / your employer. Not looking for any freebies. But if I can spend my energies *improving / extending* the efforts you and Simon / Dan have exerted instead of starting from scratch, and moreover give that back to the community... well hopefully that results in a benefit for all users in the Stripes community and puts us one step closer to having a better solution than exists today for anyone new to Stripes. Either way I sincerely appreciate your comments / feedback and Simon's and Dan's efforts to help the community. Cheers, --Nikolaos Mike McNally wrote: > 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 <mailto: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. > > > ------------------------------------------------------------------------------ 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
