Placing control references in the actor state data to control UI: good or bad idea?

[jlokanis]

[AQ Note: This was a tangent of the original thread, so I moved it to its own topic.]

Not to get off topic, but does anyone feel it is good design to make a UI actor by placing all the control refs in the actor state data and allowing messages to directly modify the front panel?

Or is it preferable to have a 'helper' loop that implements an event loop to encapsulate UI interaction and then provide the actor state data with access to user events for writting to the UI and allowing the event loop to send messages to the actor message handler for responding to user inputs?

I have only used the second option so far because I prefer to encapulate the UI outside the message handler.  And I do not consider that event handler to be an 'actor' even though it sends and receives the equivalent of 'messages'.

[Daklu]

jlokanis wrote:

Not to get off topic, but does anyone feel it is good design to make a UI actor by placing all the control refs in the actor state data and allowing messages to directly modify the front panel?

I don't think there's anything inherently wrong with it, as long as it fits your design and meets all the performance requirements.  However, I prefer to keep the message handling loop as unencumbered as possible.  I usually have one helper loop strictly to collect user input (actually it's a private subactor implemented with an event structure instead of case structure) and one or more helper loops to handle data updates.

I'm curious why you do not consider the event handler an actor.  Are you doing something with it that violates actor principles?