I don't understand (what appears to me as) some duplication in Tweak's event propagation mechanism in the bank-account tutorial http://tweak.impara.de/TECHNOLOGY/Tutorials/BankAccountTutorial/ : an ATM hooked to a bank account and displaying its balance on its #balanceReadout.
It keeps the #balanceReadout widget current by hooking into 2 separate events with 2 pieces of code:
onAccountChanged "Update the balance readout when the account changes" <on: accountChanged> self updateBalanceReadout
onAccountValueChanged "Update the balance readout when the account value changes" <on: valueChanged in: account> self updateBalanceReadout.
This seems unnecessary. If I simply declared the path to the target object being observed: { #account #value } It seems I have said enough to respond correctly to both #accountChanged and #valueChanged. The rest could be done by Tweak behind the scenes.
Such a role-chain is a common scenario: A is watching the #x of the #y of the #z. Hence A has to react to xChanged, yChanged, and zChanged (in the appropriate corresponding target objects).
Similarly, given Tweaks real + virtual fields, I'm not sure why all the on<X>Changed stuff needs to be explicit. Why not directly reference the fields e.g. Isn't the underlying event behavior adequately determined by something declarative along the lines of:
{ #balanceReadout #value } derivedFrom: { #account #value }
Is there already some better way to do this in Tweak, just not used in the tutorial?
Thanks.
There is no syntactic sugar in Tweak for this.
A simple way to "connect" fields are FieldReferences. Off the top of my head, you would use it like this:
balanceReadout player: (account fieldNamed: #value)
This sets up all the events you need to synchronize balanceReadout's value with account's #value field.
- Bert -
Am 02.10.2006 um 15:40 schrieb itsme213:
I don't understand (what appears to me as) some duplication in Tweak's event propagation mechanism in the bank-account tutorial http:// tweak.impara.de/TECHNOLOGY/Tutorials/BankAccountTutorial/ : an ATM hooked to a bank account and displaying its balance on its #balanceReadout.
It keeps the #balanceReadout widget current by hooking into 2 separate events with 2 pieces of code:
onAccountChanged "Update the balance readout when the account changes" <on: accountChanged> self updateBalanceReadout
onAccountValueChanged "Update the balance readout when the account value changes" <on: valueChanged in: account> self updateBalanceReadout.
This seems unnecessary. If I simply declared the path to the target object being observed: { #account #value } It seems I have said enough to respond correctly to both #accountChanged and #valueChanged. The rest could be done by Tweak behind the scenes.
Such a role-chain is a common scenario: A is watching the #x of the #y of the #z. Hence A has to react to xChanged, yChanged, and zChanged (in the appropriate corresponding target objects).
Similarly, given Tweaks real + virtual fields, I'm not sure why all the on<X>Changed stuff needs to be explicit. Why not directly reference the fields e.g. Isn't the underlying event behavior adequately determined by something declarative along the lines of:
{ #balanceReadout #value } derivedFrom: { #account #value }
Is there already some better way to do this in Tweak, just not used in the tutorial?
beginners@lists.squeakfoundation.org