Re: [Figleaf-developer] Questions regarding ObjectManager

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

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

> sam...@ma... wrote:
> 
> >Firstly, is this better off being named something like PersistenceLayer?
> >
> >  
> >
> Maybe. But because I had the "Informative introspect(Object obj);" 
> method in there that brought it out of being purely for persistence. 
> Also I figured there's probably going to be non-persistence stuff we'll 
> need to put somewhere (logins, security?).


If that happens we'll need to abstract out the two layers - developers might
want to change persistence mechanisms and security systems independantly of each
other.

> >Secondly, there seems to be some overlapping methods, for example (this from
> my
> >TransientObjectManager):
> >
> >public Informative newInstance(Class clazz) {
> >  return informativeFactory.createInformative(clazz.newInstance());
> >}
> >
> >public Informative introspect(Object obj) {
> >  return factory.createInformative(obj);
> >}
> >
> >Are both needed? I'm keen not to put in a requirement for methods to be
> >implemented that we might not even end up using.
> >  
> >
> 
> The introspect method was because I thought about the case if a POJO 
> creates an object (using new) and returns it from a method call. Then 
> the UI will need to get the ObjectManager to proxy it and turn it into 
> an Informative so it can be displayed. Some thought still needs to be 
> given to when such an object should be persisted: as soon as its called, 
> force the user to press a save button, or never...? 

We really need to consider if we require a PersistenceStrategy - e.g. save on
edit (e.g. call a set and its persisted ala Entity beans) or save on specific
call (hit the save button). This can probably wait till 0.2 or later, but we
need to fix on a default strategy for this version.

> Then there's the 
> issue of what if that happens in a transaction. I'm not sure it's 
> practical to expect all objects to know nothing about ObjectManager and 
> just use new. If we require them to always use the ObjectManager when 
> creating a new instance, then the introspect method probably isn't needed.

I would really, really like to have the POJOs not know about an ObjectManager -
it gives them far more than they need. We might choose to expose an
ObjectFactorty to them however (which might just be part of the current
ObjectManager).

> >As for the method:
> >
> >Informative getObject(Class clazz, Serializable id);
> >
> >Do we need this? Surely this should be handled by whatever query mechanism
> we use.
> >
> It'll probably be needed by lazy initializing proxies and collections. 
> They will only know the id and which class they represent. When they 
> need to load their data they can call this method and get a fully 
> populated object back. Perhaps it doesn't belong in the ObjectManager 
> "layer" but rather in a persistence and proxy layer.

Do we want to implement our own lazy loading mechanism, or can we just leave
this down to whichever persistence mechanism we want? Thinking about the UI, its
up to specific implementations as to what objects they want to load at any one
time - one UI when loading an object may want just that object, another might
want to load all members of that object.


sam
http://www.magpiebrain.com/