Re: Trellis on_commit and Performers

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