Speculation.. is this good practice?

[Michael Cann]

Ello All,

This is not specifically a query about RL but more about whether this is a good idea or not, im personally not sure but I was wondering if you had any opinions.

Im currently writing a database in Air using Robotlegs. I have a view with a list of tables on the left and the currently active table displayed as a DataGrid. What I want is that whenever a change occurs to a table (a change could be a row added, row removed, schema change, cell edit etc etc). 

What I was doing previously was to have a number of signals on each table for the various events "rowAdded" "rowRemoved" etc. Then in the TablesListItemRenderer I was listening for all the various changes on the table. The problem was I was getting in quite a mess. Firstly the view itself was starting to look pretty ugly with lots of signal.add and signal.remove calls. Secondly it was getting complicated to detect a table change particularly when a cell edit would need to bubble up from the cell to the row then to the table etc. 

What I decided was instead of having the signals on the Table, Row, Cell etc, instead put all the signals in a single "SignalBus" so for example:

public class SignalBus

{

public var rowAdded : Signal = new Signal(Row);

public var rowDeleted : Signal = new Signal(Row);

public var cellEdited : Singla = new Signal(Cell);

public var tableChanged : Signal = new Signal(Table);

}

Then in the context I mapped as a singleton and had that injected into all my tables, rows, cells. When one of these events occurs they instead dispatch the signal bus signal with 'this' as the parameter. 

Then I wrote TablesListItemRendererMediator:

public class TablesListItemRendererMediator extends CoreMediator

{

[Inject] public var view : TablesListItemRenderer;

[Inject] public var bus : SignalBus;

override public function onRegister():void

{

addSignalListener(bus.cellEdited, onCellEdited);

addSignalListener(bus.rowAdded, onRowAdded);

addSignalListener(bus.rowDeleted, onRowDeleted);

addSignalListener(bus.tableChanged, onTableChanged);

}

private function onTableChanged(t:Table):void

{

if(t==view.table) view.update();

}

private function onRowDeleted(r:Row):void

{

if(r.table==view.table) view.update();

}

private function onRowAdded(r:Row):void

{

if(r.table==view.table) view.update();

}

private function onCellEdited(c:Cell):void

{

if(c.row.table==view.table) view.update();

}

}

This way I am able to shift the listening out of the view and into the mediator.

Is this how you guys would have solved this problem? Or is there a better way? Is a 'global' signal bus a good idea?

--
Mike Cann
http://www.mikecann.co.uk/

@mikeysee

[Neil Manuell]

My two cents:

Why are you listening to the table?

why not alter the data, then have the table modify itself to fit the model?

for example, you don't add a row to the table, you add an element to the data, and the table, bound to the data adds a row?

--
You received this message because you are subscribed to the Google
Groups "Robotlegs" group.
To post to this group, send email to robo...@googlegroups.com
To unsubscribe from this group, send email to
robotlegs+...@googlegroups.com
for support visit http://knowledge.robotlegs.org

[Michael Cann]

Not sure I totally understand.

The table holds the data. So for example every table has a name and a description field. Are you suggesting I have a TableData class too?

[Michael Cann]

Lol I just read my mail back, I missed that what I want to happen when a change occurs, I want the table in the TablesList to change color to red to indicate that there are 'unsaved' changes.

Hope this make a little more sense now ;)

[Avi Kessner]

Makes sense to me.  Except for this line:

if(c.row.table==view.table) view.update();

I'd expect it to be c.table like the rest.

As for your actual question, I see two ways of looking at it.

1. Centralizing your events makes it easier to see the flow of the program. Less jumping back and forth between classes to figure out what actually happens when you press a button. In some ways it also makes it easier to maintain.

2. Centralizing your events gives your events hub too many responsibilities and too many dependencies that may not actually be related to each other. 

Personally, I think in this case 1 applies and 2 does not.  You might end up adding more events like, "cellMoved" or "rowMoved" or ColumnAdded etc, but I can't see you adding in anything to this class that doesn't clearly apply to updating what this table is capable of doing.

brought to you by the letters A, V, and I
and the number 47

[Michael Cann]

Hi Avi,

Thanks for that. "if(c.row.table==view.table)", a cell belongs to a row, a row belongs to a table, I could put a shortcut in there I suppose. 

Yes, I think in this case 1 wins out. The reason why I bring this question up here is I have run into this sort of thing several times. In essence; do you have the view listen for changes on the object or do you have the object dispatch a global event to the bus and have the mediator listen to the bus and update the view?

[Neil Manuell]

I think thats your call. 

either way makes simplifications in some areas, and complications in others

isn't it the old presentation view vs mediation argument

[pixels4nickels]

I would probably try and assign the collection to the view (through the mediator) then manage the collection events in the mediator, in order to keep the view decoupled from the data (as Niel suggested). You should be able to discern almost all types of operations from those events. I love signals myself but there are certain cases where I feel they can still make more sense, like isolated in the mediator from the UI.

my $0.02,
Ken