This would be optional, the current way would still be supported.
Do you have a better solution to add constraints to existing POJOs
that can't or shouldn't be modified?
On 30-okt-05, at 16:50, Keith Lea wrote:
I think requiring 2 classes for each bean sucks. I know it won't be
required,
Hello,
I'm a newcomer who try to run the examples (atm I'm stuck with chapter
8; may be my next email ;-)), but may I suggest :
- to keep an option with Rife as it is,
- to add an option Rife with AOP, and use for example Spring
capabilities or even AspectJ
Regards
Pierre
Geert Bevin
I think this is fine. While I don't know if I would ever use it (I suspect I would) I think it fills a void.
I think the implementation that Geert suggested is perfect (except that
his POJO extends something, but I'm sure that is a typo).On 10/30/05, Geert Bevin [EMAIL PROTECTED] wrote:
As I said
Hi Geert,
yes, that seems clear by your example. Nevertheless I am currently
thinking about pros and cons of a repository. Though this has not been
used in your examples I could think of the need for different
validations for one single pojo.
Your default way would either be the current
yes, that seems clear by your example. Nevertheless I am currently
thinking about pros and cons of a repository. Though this has not
been used in your examples I could think of the need for different
One think that's maybe not clear, is that the repository would track
the mappings of Pojo
