[Figleaf-developer] Re: current state of Introspector
Status: Alpha
Brought to you by:
steckman
|
From: Greg S. <ste...@on...> - 2004-07-11 14:54:18
|
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 |