Re: Trellis on_commit and Performers

"Phillip J. Eby" <pje-Wh6+Hckhi6HFNGf7iClzIwC/[email protected]>
Newsgroups gmane.comp.python.peak
Message-ID <[email protected]>
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.)
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.