Re: [Figleaf-developer] Questions regarding ObjectManager

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

sam...@ma... wrote:

>Quoting Greg Steckman <ste...@on...>:
>  
>
>>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.
>
>  
>
Very possible.

>>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.
>
>  
>
For now I put in a save button on the Form view. I think this meshes 
well with validation, because when the user wants to save, the object 
can be validated once and if it fails an error presented. I can imagine 
situations where an object needs to be validated after all its data is 
entered, rather than after each field is changed.

>>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.
>
>
>  
>
I think when we get to implementing remoting, we'll have to put in some 
type of lazy loading and caching implementation. That implementation 
should then be usable on the server or remote end. It's certainly 
something I don't want to start implementing at this point yet. Since 
I've used Hibernate, I think there will be some issues with how it does 
lazy loading and the requirement to keep sessions open. Also there is 
the case of needing to introspect to make informative objects when 
lazily loaded. If our container doesn't control the loading, I don't 
know how to know when to introspect the object.

Greg