[PEAK] using peak model & storage in a GUI

Thu Apr 7 07:32:38 EDT 2005

On Wed, 2005-04-06 at 22:07 -0400, Phillip J. Eby wrote:
> 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.
> 

This is correct - i haven't finished my experiments building a
GUI-framework for peak and it might not be the most elegant way i went.
I didn't work on this issue for a while so the system doesn't use the
latest features/patterns of peak very much 
(e.g. adaptation/generic-functions).

The Idea is/was to build a n-tier Client-Server-System with
RDBMS/...-Backend and a Domain-Model with Businessrules (statemachine or
rulesets) on the server, talking to a browser-like rich-gui-client using
a message-bus (e.g. twisted's perspective broker or jabber). the whole
system is build using peak's components/configurations/...

to achieve this, i built a couple of packages: 

nll -> core services and extensions to peak 
        (e.g. more db-connections, sql-schema-support, 
         tales-expressions, [not finished]network-transports)

nllworkflow -> StateMachine-Implementaion (UML 1.3 compatible)
                        with composite states (no concurrency)

nllgui -> a peak.component-model for wxWidgets with a simple 
              model-data-serializer and an extended xrc-parser
             (pre 2.5 - they changed the lib-structure afaik)

nllreport -> create PDF-Documents with some self-defined markup (PML)

all this is available from my cvs-server:
http://cvs.net-labs.de  --> libs/...

or 
cvs -d:pserver:anonymous at cvs.net-labs.de:/data/cvs login
password: <empty>
cvs -d:pserver:anonymous at cvs.net-labs.de:/data/cvs co libs

there is an example that put's it all together called modelexplorer
in the package nllsandbox/gui_components/modelexplorer

the stuff is experimental and doesn't work out of the box probably !!!

the whole project has reached a far amount of complexity that is 
not trivial to explain in a few lines .. i'll give it a try:

preconditions for model-explorer: 
 - a model-element is reached via a path e.g. /users/<name>
   (this is selected using a tree-widged in modelexplorer)
- it's a request-response based system to allow the tiers to be 
  distributed over the network (in case of model-explorer 
  all this happens inprocess by looking up an EventChannel)
- in model-explorer a statemachine controls the behaviour of the gui
  (workflows.xml) and a resource file defines form-elements and events
  which are not autogenerated from nllgui (modelexplorer.xrc)
- the system uses microtransactions (e.g. getData or setData for an
IValueLink(Element)
  is encapsulated in a transaction)

a typical request to open a new editor-panel filled with data might look
like this:

- actor double-clicks on the tree-item to open a editor-panel
- panel is loaded and requests data from the server for path
"/user/jack"
- request-message is sent to the domain-model
- the domain-model traverses to the Element and adapt's it to
IValueLink  
  (IValueLink(<element>).getData() extracts the data from an
model.Element 
  into a simple structure of Structs/lists/values that is easily
marshalled and sent 
  through the wire. using the "schema" information from peak.model one
can 
  restore this structure into a model.Element.)
- the response with Element-Type-Info and ValueLink-Data is sent to the
client.
- the client creates the editor-form using the ElementType-Info and
fills the
  form with data using the ValueLink-Data (there is no coupling between
the 
  domain-data and the form-data)
- in future there might be update/change-events from peak.schema which
are
  sent to the client(s) (subscribed while data is displayed/worked with)

then the actor uses the editor-panel and e.g. changes a few values
(which in case of model-explorer triggers the apply/save buttons to be
enabled) and then the actor click's on the save button.

a typical request to save and close the editor-panel might look like:

- user clicks on save-button to finish editing
- client sends a change-message for "/user/jack" to the domain-model 
- change-message is created (TBD)
- domain-model is changed in a microtransaction
- response signals sucessful update
- panel is closed

the interesting part for extracting data from an element is in:
http://cvs.net-labs.de/cgi-bin/viewcvs.cgi/libs/nllgui/src/nllgui/guischema.py
ValueLinkForElement::getData

hope this helps a bit

Ulrich

> 
> >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.)
> 
> 
> _______________________________________________
> PEAK mailing list
> PEAK at eby-sarna.com
> http://www.eby-sarna.com/mailman/listinfo/peak
-- 