Re: [Figleaf-developer] No need for proxies - at least at the moment

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

Hi Sam,


sam...@ma... wrote:

>Quoting Greg Steckman <ste...@on...>:
>
>  
>
>>sam...@ma... wrote:
>>
>>    
>>
>>The object returned must be an "instanceof" the object I wanted. Would 
>>this do that?
>>    
>>
>
>Do, but why does it need to be an instanceof? Surely the UI wuold just call
>'getProperties' to expose the right views, which does it need to know the
>specific class?
>
>  
>

The UI will in some cases take one object, that is visible, and pass it 
to another object that is visible as a method parameter or to a property 
setter. If the first object isn't of the expected type, there will be a 
problem. I planned on having the UI inspect the class/interfaces objects 
implement when determining if they matched the types expected. If the 
object the UI has is really a delegate that doesn't implement all the 
interfaces and class hierarchy of the real class, then there will have 
to be extra code like "instance.getRealInstance()". But now that "real" 
object which will be used to set a property, won't implement Informative 
and therefore property set calls made to it by the second class won't 
have events fired, for example.

>If by non-property methods you mean the 'action' type methods from NakedObjects
>this is still not a problem - we can add in the concept of these via your
>message descriptors to the object returned from the factory
>  
>
That's what I meant.

> 
>  
>
>>Currently there are interfaces defined which allow the following:
>>
>>Informative myInformative=theObjectManager.newInstance(com.foo.bar.class);
>>PropertyDescriptors[] 
>>pd=myInformative.getClassDescriptor().getPropertyDescriptors();
>>MethodDescriptors[] 
>>md=myInformative.getClassDescriptor().getMethodDescriptors();
>>myInformative.getClassDesctiptor().getDisplayName();
>>myInformative.getClassDesctiptor().getDescription();
>>etc.
>>
>>I think this essentially is the same as what you are proposing. All the 
>>"magic" happens in the ObjectManager.newInstance call (and other methods 
>>that return Informatives). But the following constraints should be 
>>maintained:
>>
>>myInformative instanceof Informative evaluates to true
>>myInformative instanceof com.foo.bar evaluates to true
>>    
>>
> 
>Again, why does the UI need to know of the actual underlying class?
>  
>

See above.

> 
>  
>
>>The array of PropertyDescriptors is not a problem (at least for a UI 
>>generator) because it will add them all to the UI (in the order as 
>>returned by the object). There is no need for the UI code to invoke a 
>>property by name. It maintains references to the PropertyDescriptor and 
>>then just invokes the readMethod or writeMethod when required.
>>    
>>
>
>So the PropertyDescriptor has readMethod/writeMethod? If the user can define
>their own PRopertyDescriptors (as we have planned) we are then allowing them to
>change what is invoked. Also, I thought that your PropertyDesciptor is
>class-sepcific rather than instance-specific - in which case you'll have to pass
>in the actual instance to invoke the read/write method, which leads to this:
>
>bean.getProperty(propertyName).invokeGetter(bean);
>
>which looks a little strange. However I should remember what I said earlier -
>lets settle on the simple cases to get a version out...
>
>  
>
Check the PropertyDescriptor interface - it's pretty simple, allowing to 
get the property read and write Methods. I more or less took inspiration 
from the Java Beans API (java.beans...) but using a lot more interfaces 
for added implementation flexibility and stripping out what I thought we 
didn't need.

>>I almost have a whole slice working with objects that implement 
>>Informative on their own. The only missing piece would be to implement 
>>an Introspector that knows how to make a proxy that implements 
>>Informative given an object instance that does not.
>>    
>>
>
>Which I have - I  also have it implementing Observable. I would say that for the
>first version we provide the implementation of Observable and add the code later
>on which will allow users to define their own. 
>
>  
>
For now I'd even settle for just requiring objects to implement 
Informative completely themselves and get the persistence and UI layers 
worked out. It'll then be a functional platform to some extent. That's 
the approach I've taken so far.

Greg