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
