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.)