-dain
On Wednesday, January 29, 2003, at 11:40 AM, Sacha Labourey wrote:
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 decodestuff)
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
------------------------------------------------------- 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
