OK, you're the chief, I trust you! > -----Message d'origine----- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]De la part de Dain > Sundstrom > Envoye : mercredi, 29 janvier 2003 18:49 > A : [EMAIL PROTECTED] > Objet : Re: [JBoss-dev] Feature request, dev assignments > > > 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 : [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 > > > > ------------------------------------------------------- > 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
