Dain,

I agree, this is some of a hack, but any trick would be hack because it
requires the container to implicitly do some call. What your container
bytecode implementation generates is something like that (very pseudo-code
as we all know it is something like "invoke"):

        public void setXXX (Object bla)
        {
                doMyPersistenceThingForXXX();
        }

I was only suggesting something like:

        public void setXXX (Object bla)
        {
                if (XXXSeterImplementedBySuperClass())
                        super.setXXX(bla);
                doMyPersistenceThingForXXX();
        }

Pro:
        - very simple for both your code and the developer code
        - no need to have 2x the same setters (or getter if you want to decode
stuff)

Cons:
        - proprietary
        - you could just (setters) deny access by throwing an exception but not
modify the actual content of what is stored. This is a real miss. The Veto
thing would also need to be extended for this. Some people have to trim
white spaces for example.

Nothing magic here.

cheers

sacha

> -----Message d'origine-----
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de Dain
> Sundstrom
> Envoye : mardi, 28 janvier 2003 01:56
> A : [EMAIL PROTECTED]
> Objet : Re: [JBoss-dev] Feature request, dev assignments
>
>
> I never really liked this idea.  I think you should provide a concrete
> setPostalCode (String code) method and if the data is valid you would
> call setPostalCodeField (String code) or setPostalCode_(String code).
> I think this type of validation is part of the business logic.
> Alternatively, there are types of validation that are really an aspect
> (deployment environment specific).  For example, a company specific
> mail route field.  The validation of this field would depend on the
> deployment environment (which company it is deployed at).  In this case
> I see an interceptor, possibly a Bean Scripting Framework interceptor.
>
> What I am getting at is I think this proposed solution is a hack and I
> personally would not accept the patch, but the user community has
> convinced me to include things I consider hacks.
>
> -dain
>
> On Monday, January 27, 2003, at 08:31 AM, Themba Mbatha wrote:
>
> > Hi all;
> >
> > What would be the procedure if one is interested in implementing a
> > feature request? There is a feature request (647669) that I also need
> > a.s.a.p. and I'm prepared to contribute the implementation once I'm
> > done.
> >
> > Regards.
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.NET email is sponsored by:
> > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> > http://www.vasoftware.com
> > _______________________________________________
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to