[Figleaf-developer] Re: current state of Introspector

[<sam...@ma...>]

Quoting Greg Steckman <ste...@on...>:

> Hi Sam,
> 
> I was having a look at your introspector code again. We might rethink 
> how to handle multiple interfaces. For instance what if I have a class 
> that implements all of Informative, but it is a helper class not the 
> "real" class? Perhaps we need to look for a class called 
> o.getClass().getName()+"Informative" and it must implement Informative.

Which i do support now for ClassDescriptors - if you pass MyClass into figleaf,
the introspector looks for a class MyClassClassDescriptor on the classpath and
uses that as the Informative implementation. Ideally we could expand this - have
MyClassObservable, MyClassClassDescriptor etc, and allow figleaf to handle some
aspects of this automatically.
 
> Also this helper class will probably need to get a reference to the 
> underlyingObject at some point in order to do its work correctly. We 
> might want to impose that these helper classes have a single parameter 
> constructor that takes the underlying object as argument.

Yep - its an easy matter if I find the helper class (as detailed above) to
locate the correct constructor to instantiate. We could even take the same
appraoch with something like a PropertyDescriptor if we wanted to make them
instance specific.

> In InformativeImpl you have implemented change listeners, but it looks 
> like only if the caller invokes setProperty(String propertyName, Object 
> value). But that method isn't in any interfaces, so I don't think it'll 
> ever get called. I think the listener functionality needs to be placed 
> in the proxy implementation, in the InformativeCallbacks method.

Erm, these methods *should* get called (InformativeImplTest) - they should be
implementing the methods defined in Observable. I don't have any tests for
InformativeImpl, I'll add some.
 
> If it's ok with you, I can make these changes and reduce some of the 
> redundancy between the interfaces I made and the ones you made.

I will improve support for locating the helper classes - I can refactor out some
helper classes for the job so it should be an easy job. I'm not sure
InformativeImpl needs to be changed as its listener methods should be working
fine. I do need to allow the users implementation of Observable to be called -
at present my implementation is always used...

I have made one small change to your code for thr purposes of my validation
implementation - I changed the PropertyDescriptor version on my local code to
not return Method objects. It still takes the read and write methods in to an
object, it just abstracts out the calling of these methods. Changing your view
code actually involved removing rather than adding code. I also added an
AbstractPropertyDescriptor class to allow easy definition by the developer, so
now they can do:

PropertyDescriptor nameProperty = new AbstractPropertyDescriptor(String.class,
"Name", "The things Name") {
public Object read(Object target) {
				return getName();
			}

			public void write(Object target, Object value) {
            	setName((String)value);
			}
		}; 
> 
> P.S. I still only get some of the mails sent to the list, so it's best 
> to CC me for now.

Will do


sam
http://www.magpiebrain.com/