[Zope-PTK] Re: PropertySheets

Phillip J. Eby pje@telecommunity.com
Thu, 10 Feb 2000 18:06:03 -0500


At 06:18 PM 2/9/00 -0500, Mike Pelletier wrote:
>
>    I've done some reading in OFS/PropertySheets, and it seems to me that
>the FixedShema class (a PropertySheet subclass) accepts as a constructor
>arguement another PropertySheet, which it uses as it's schema and for
>default values.  It would be trivial to subclass this in such a way that
>it can ask a UserStore for it's values, and to tell the UserStore when it
>changes it's values.  For now, let's call this subclass 'LoginSheet'.
>
>    So.  LoginManager is given a PropertySheets object, pstemplates.  
>This contains a set of PropertySheets.  This allows the manager to define
>a schema and default values with very little work on our part.
>
>    LoginUser is given a PropertySheets object called propertysheets.  
>When (or shortly after) a LoginUser is instantiated, it iterates over the
>LoginManager's pstemplates, creating a LoginSheet object for each of
>pstemplate's PropertySheets.  The LoginSheet calls a method on the
>UserStore with the username and propertysheet name as arguments.  The
>UserStore method returns a mapping of names to values, which the
>LoginSheet uses to populate itself.

Actually, my thought was to have "propertysheets" be a ComputedAttribute on
LoginUser objects, which calls a "sheetsForUser" method on the UserSource.
Further implementation could be left to the UserSource.  Of course, if the
user object is itself in the ZODB, then propertysheets could be a
persistent attribute, and not delegated.


>    If the fetch-properties and store-property methods don't exist on the
>UserStore, they can be aquired from the LoginManager which would provide
>the services by stashing the information in it's instance somewhere.  
>This way, UserStores don't _have_ to provide this support.  If they don't,
>properties are simply stored in the ZODB, and we're no worse off than we
>are now.

My thought is that the user stores would take SheetProvider plugins.  The
propertysheets object returned by the sheetsForUser method could query the
plugins whenever it is actually used.  Again, this is so that there is no
instantiation overhead for things which aren't being used at a given point
in time.

If you want a sheet to be in the ZODB, then you plug in a ZODBSheetProvider
for that sheet, or the UserSource might just store them all in a
username=>propertysheets mapping object.

Hmmm.  I think I know how we can do this.  We'll have LoginUser.__init__
take parameter(s) indicating whether a dynamic or static "propertysheets"
is to be used, so it can set a ComputedAttribute for dynamic, the actual
data for static, or leave the propertysheets attribute non-existent if
neither.  Then we'll add "sheetsForUser" to the BasicUserSource interface.
Last, we'll look at how GenericUserSource might "outsource" the
propertysheets implementation.

Note: I'll be out of town Friday through Monday, so I'm not sure this'll be
done quickly.  I've been bombarded with meetings and emergencies all week
which is why it's taken so long for me to comment on this.