[PEAK] Trellis on_commit and Performers

Phillip J. Eby pje at telecommunity.com
Fri Oct 3 11:56:46 EDT 2008


At 05:29 PM 10/3/2008 +0300, Sergey Schetinin wrote:
> >> I also wonder if I'm trying to make Trellis do something it can't.
> >> What I'm trying to do is to collect all the data required for certain
> >> operation with side-effects and perform it in on_commit. That
> >> operation also changes some Trellis cells which then should trigger a
> >> set of performers that would modify the newly created
> >> (non-trellis-managed) object.
> >>
> >> To work around this, I changed the code to schedule the call by other
> >> means than on_commit, so the second round of changes happens in a new
> >> transaction, but I wonder what's the intended way to accomplish this?
> >
> > Why can't you just use a maintenance rule that depends on the accumulated
> > data, and let the trellis arrange things in the right order?  I don't see
> > why you need two transactions here.
>
>That's because second transaction depends on data read from objects
>created in the first transaction.
>
>In my case there's a generic Frame class. The app issues a command to
>create a wx backend for it which also does the same for its children.
>After that happens the generic implementation is switched to read /
>write the backend properties (which are Trellis managed as well). So
>if something depends on Frame.size the chain of dependencies will make
>it subscribe to EVT_SIZE events. So, if we have a layout manager
>working on these generic instances, once the backend is created it
>will detect actual sizes of windows and work with that.
>
>The layout is implemented as a @maintain rule. It couldn't work in the
>same transaction as @perform's that create and initialize the backend.

I still don't follow.  However, if you're saying that you need this 
because the wx changes you're making in the performer cause a 
recursive wx event to fire, then the solution is to forward-schedule 
the wx API call(s) so they don't happen in the same wx event.  That 
is, push the wx stuff into a new transaction, rather than the trellis changes.

(I don't know if this is actually the issue you're having; if not, 
please explain in more detail or show code.)




More information about the PEAK mailing list