Le Vendredi 2 ao�t 2002, � 12:08 , John McNally a �crit :
> I'm not opposed to this patch as it gives better java style variable > names. But I do not see how this violates the JavaBean spec. The spec > says that if an object has an attribute, foo, it should have public > getFoo/setFoo methods. There is no reason it has to have a private > instance variable called foo. It can have whatever private > attribute/variable names it needs. > > One problem you can see with torque and ParameterParser.setProperties is > torque's overloading of the attribute setters. It is obvious in the > case of overloading which is the correct bean setter if a getter is > present, but the Introspector is buggy. Its possible that only one > setter is allowed in beans. I don't remember reading this in the 1.0 > spec, but I do remember some discussion that it is required. Torque > provides a property to turn off the setter overloading. Use it if you > are having problems with the Introspector. > My own patch partial workaround on this (I am working on this issue right now) has been to change the order of the setters in the torque.jar:om/Object.vm so that they go setXXX(String) setXXX(ObjectKey) instead of the reverse. (This is around line 129 in the 3.0b3 release; and again around 1090 for the Primary key) This helps the Introspector (quite a buggy class, BTW, and too closed to enhance... <sigh/>) to guess correctly that the key is actually of type objectKey (or a subclass thereof) and not String. I strongly recommend incorporating that simple change in the repository, as it will make all beans happier. BTW, I am also beginning to think of generating BeanInfo classes alongside the BaseSomething.java Ideally, that would allow me to control which fields are persistent/transient: I am trying to generate meaningful XML (with the java.beans.XMLEncoder) but that is turning into a nightmare as Torque ensures that each object in the model knows all other possible objects. Making a few of the links transient is a way for me to avoid this. Another thing I had to do, that I'll offer to anyone interested, is a patched version of the XMLEncoder and friends (again, if everything in the beans package were not needlessly private, I could and would do this cleanly...) which accepts a torque-optimized PersistenceDelegate. (A trick here is to ensure that the primary key gets processed LAST, otherwise all other Object values are deemed to depend on it and do not get written out.) Anyway... Back to the grinder Marc-Antoine Parent -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
