From: Dain S. <da...@da...> - 2003-01-29 17:50:08
|
I don't know, but we could create our own listener to support modifying the value. I'll have to think about the implications that. We plan on supporting notifications from the backend also, so changing the value may be problematic. You will also be able to have many entities fields mapped to the same column. . . . Maybe we should have two listener interfaces: one for local changes and one for backend changes. Anyway, I simply prefer a listener approach to an implicit method call. -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 : jbo...@li... >> [mailto:jbo...@li...]De la part de >> Dain >> Sundstrom >> Envoye : mercredi, 29 janvier 2003 18:35 >> A : jbo...@li... >> 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 : jbo...@li... >>>> [mailto:jbo...@li...]De la part de >>>> Dain >>>> Sundstrom >>>> Envoye : mardi, 28 janvier 2003 01:56 >>>> A : jbo...@li... >>>> 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 >>>>> Jbo...@li... >>>>> 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 >>>> Jbo...@li... >>>> 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 >>> Jbo...@li... >>> 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 >> Jbo...@li... >> 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 > Jbo...@li... > https://lists.sourceforge.net/lists/listinfo/jboss-development |