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

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

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

> sam...@ma... wrote:
> 
> >I had a major brainwave last night and realised we don't need proxies at
> all.
> >Here is my new proposed workflow for introducing developer-defined beans
> into
> >the system.
> >
> >1. The ProxyFactory (now needs to be renamed) gets given an object
> >2. It invokes an ObjectIntrospector to retrieve an Informative
> implementation
> >3. It creates an implementation of the new interface Bean (needs a rename?)
> >which implements Informative and Observable. In addition it defines two new
> methods:
> >
> >Object getProperty(String propertyName);
> >
> >void setProperty(String propertyName, Object propertyValue);
> >
> >These methods fire change events accordingly without any need for proxied
> method
> >interception.
> >
> >4. This is returned to the UI layer (or whatever).
> >
> 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?

> >
> >5. To interact with this developer defined object, the UI first gets a list
> of
> >properties to expose them (which comes from the underlying Informative
> >implementation). To invoke a method, it calls getProperty() or
> setProperty()
> >with the relevent property name.
> >
> >This removes the need for all proxies, results in easier to test, less
> >complicaed code, and I think gives the UI evervything it needs. We may
> still
> >need proxies for remoting/securirty/validation or whatever, but for the
> moment
> >it doesn't look like we need to.
> >
> 
> How does the UI then access non-property methods of the object? The 
> object needs to be able to expose to the UI actions that can be invoked 
> by the user. That is the main purpose of the MethodDescriptors.
>

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
 
> 
> 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?
 
> 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...

> 
> 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. 

sam
http://www.magpiebrain.com/