Re: Re: Trellis-fork

If you were working Sensors and Connectors it could have crossed your
mind that connect and disconnect methods are actually a kind of event
handlers themselves -- the event being the change in presence of
listeners to the sensor. That is events effectively being "we want to
observe this cell (a LazyCell for example)" and "not anymore". But at
the same time the implementation of this event handling was completely
different from what Trellis generally offers -- you actually need to
provide the event handlers instead of just observing some cell.

The changes I've committed today change that -- every cell, even a
Value gets a .has_listeners attribute that acts as a cell -- if you
read it from a rule it will retrigger it when the cell gets any or
loses all its listeners. One of the things this buys you is that
connect / disconnect don't have to be very fast operations anymore.
Imagine a cell representing some remote data, establishing the
required connection, asking the server to send updates and other
bootstrapping might take a while, with this change it doesn't have to
happen inside single transaction anymore.

Another reason why this is useful is that it allows one to make
normally passive cells become active by means of some external
component. It would work like this: if a Value is observed --
.has_listeners -- make arrangements to update it as necessary. It's
good to know that the same would work even if the target cell is not a
Value which is something that makes the alternative strategy (replace
cells with our own implementation) more fragile. The downside is that
unless subscribed to that Value would just stay out of date.

Another result is that LazyCell is not a Sensor anymore, but a direct
descendant from ReadOnlyCell.


-- 
Best Regards,
Sergey Schetinin

http://s3bk.com/ -- S3 Backup
http://word-to-html.com/ -- Word to HTML Converter