[PEAK] using peak model & storage in a GUI

[Phillip J. Eby]

At 06:44 PM 4/6/05 -0700, Dave Peticolas wrote:
>Hi, I have a few questions about using PEAK.model and PEAK.storage in
>a rich GUI client. Are there any examples of using PEAK with a GUI out
>there?

I think Ulrich might have some.


>It seems that you might use the PEAK models you create for an
>application's data model as the basis for the GUI models of a
>Model-View-Controller design. When a model is loaded with a data
>manager, though, it will lose all of its state after the transaction
>is closed. It seems resetStatesAfterTxn controls this, but I wonder if
>there is a good reason not to set it to False?

Well, if some other process can change the data, then it will become stale 
unless you have some other mechanism in place to handle that.  So, that's 
at least one good reason not to do it.  :)


>Also, you cannot change the models outside of a transaction and I'd
>like to avoid leaving a transaction open during a potentially long
>editing session.
>
>Is there an easy way to 'unhook' a model from a data manager?

Easy?  Not really.  You'd pretty much have to have a two-layer system for 
that.  Frankly, PEAK's current transaction model and DMs were designed for 
a server environment with "instantaneous" transactions, not long-running 
GUI transactions.  When peak.schema lands, there will be better support for 
creating "rich client" software with PEAK.


>Is this a reasonable way to use PEAK models in a GUI?

Pretty much the best way to create something like this with the current 
architecture is to create DM's that expect to talk to a "middle tier" 
server that then performs the entire database transaction in one go, and 
reports back any conflicts.  IOW, you don't hold a DB transaction for the 
duration of your user's operations.

In the post-peak.schema world, this will be a bit easier because there will 
be less coupling between objects and the database(s) that store them.


>I'd also like to get event notifications when a model is changed.
>Would it be appropriate to make a model an IEventSource and then
>wrap the get/set/unset methods of a model's attributes to generate
>change events?

Yes, albeit a tedious way.


>Is there an easy way to adjust attribute behavior
>model-wide without using a new metaclass?

No, there isn't, and that's one of the driving forces behind the design of 
peak.schema.  You can see an example of what that will look like from the 
links here:

     http://www.eby-sarna.com/pipermail/peak/2005-March/002167.html

That is, in some of my work for OSAF I prototyped an API that's very much 
like a scaled-down version of my plans for peak.schema.  It implements 
model objects using an event-driven basis, and uses the events to do 
constraint maintenance and persistence, rather than building persistence 
directly into the objects.

Unfortunately, there is no set date for peak.schema to arrive, and PEAK 
isn't an OSAF project, so I don't get to do it during working 
hours.  Currently my off-time development priorities are roughly:

    * PyProtocols 1.0a0  (experimenter-ready generic functions)
    * Python Eggs (binary distribution format for Python packages)
    * peak.web and peak.schema, in no particular order yet

So, at the current rate of things it could easily be a couple of months 
before I get down to doing anything substantial on peak.schema.  It's going 
to involve a lot more than what I implemented for OSAF, but on the other 
hand I'll be able to use generic functions, where my OSAF work couldn't 
without introducing a new dependency (i.e. PyProtocols).

Anyway, you should be aware that I currently consider peak.model and the 
DataManager framework to be "legacy".  They'll probably be maintained for 
at least a year, though, before they get sidelined to a separate egg from 
the main PEAK distribution.  (I.e., you don't get them unless you want them 
enough to hunt them down.)