Re: Entity Facts

Le jeu 01/05/2003 à 01:34, Alex Black a écrit :
> > Why do you think to a tree for storage ?
> 
> Because you want to have the ability to open a transaction context just for
> a (for example) Forum Post app, and a transaction context for something else
> at the same time, and have them both reside in the global context.

Are you sure it's not simply a list of TransactionContext rather than a
tree ?

> > Why do you call it TransactionContext and not Storage ?
> 
> Well, I think we need to handle both transaction contexts and storage, and
> the two may be separate.

So we would have:
    Entity                  TransactionContext           Storage
    - php class             - handles query ?            ??
    with GetProperty()      - store db state ?           
    SetProperty()           - maps db to object
                            and object to db
Could you detail more the distinction between both, i don't get this
point.

> > What is it useful for ? Entity.xml -> Entity.object by xsl
> > and probably                       -> Set of prepared sql queries
> > Should the transaction context know of some details from the def or
> > asking the object, i don't know.
> 
> You don't want to instantiate an entity class with its definition for each
> record because you then duplicate the definition in memory over and over and
> over...

I meant the definition was transformed at build time into a php object 
whis is 'aware' of the properties names and type (linked with
validators); so what info would be missing in the object and present in
TransactionCOntext ? only table and datasource name ?

--

-- 
Jean-Christophe Michel <jc.michel@...>
Symétrie