[Figleaf-developer] Re: current state of Introspector

[Greg S. <ste...@on...>]

sam...@ma... wrote:
> I think we need to get this sorted properly. With that in mind, I'm going to
> write some integration tests for my validation work, check it in and move back
> to this - we can pick up the validation/changeset stuff later. The integration
> tests can act as a proof of concept so we can come back to it when we have a
> better idea as to how a developer will define figleaf applications.
> 
> For the introspector this is my overview of how things stand:
> 
> 1. We have a two interfaces that have to be implemented by an object in order
> for it to be useable in figleaf:
> -- ClassDescriptor
> -- Observable
> Which together make Informative
> 2. If an object implements Informative, no action is taken
> 3. If an object implements one required interface but not the other, then we
> look on the classpath for the other, e.g. it implements ClassDescriptor but not
> Observable, then we look for Observable
> 4. If a required interface cannot be located on the classpath, we create a
> default implementation
> 
> All of this is hidden behind the existing InformativeFactory code - the changes
> will be completelty transparent to your GUI code.
> 
> Sound ok?
> 
> sam
> 
> 
> 


That sounds good. That's what I had in mind.

There is one additional case:

3b. If an object implements no required interfaces, then we look on the 
classpath for it, e.g. we look for Informative.

There could be issues of how to handle this if we have n interfaces 
(instead of just 2). For example, what if the object implements 2 and we 
need to look for implementations of the other n-2? That's too 
complicated, so we should require the object to either implement 
Informative, part of Informative, or none. In the case it implements 
part of Informative or none, there should be 1 class to look for. For 
those interfaces not implemented between the two classes, a default 
implementation is provided.

So say there is class MyClass implements interfaceA, interfaceB; Then to 
make an informative look for "MyClassInformative" which might implement 
interfaceC, interfaceD (or whatever) to augment it. I think this makes 
the logic of what to look for simpler and allows a single helper class 
to implement multiple interfaces that make up Informative.

I know at the moment Informative only has 2 superinterfaces, but I think 
we should leave the flexibility to add more without having to make 
changes to the introspector.

Greg