But would this allow some observer to modify the actual content of what is set (setter) or returned (getters)? This is the second part of the interest IMHO.
> -----Message d'origine----- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]De la part de Dain > Sundstrom > Envoye : mercredi, 29 janvier 2003 18:35 > A : [EMAIL PROTECTED] > Objet : Re: [JBoss-dev] Feature request, dev assignments > > > Sacha, > > What you suggest would require rewriting the byte code generator, which > I didn't write. Currently all the implementation of the abstract > methods does is call an invocation handler. > > I do really like the idea of the PropertyChange[Veto]Listener and have > already added it to the task list. This fits into our (the cmp team) > plans to add change notification (observer pattern). > > -dain > > On Wednesday, January 29, 2003, at 01:45 AM, Sacha Labourey wrote: > > > 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 > > > > ------------------------------------------------------- > 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
