I have a small problem with several solutions, but I don’t like any of them. I appreciate ideas / suggestions:
A TableListBox with its respective TableListBoxModel.
I’ve implemented “cellClicked” on the model, and in response to the click I add an item to the model. This means that the TableListBox needs to update its contents (because on creation of this item, I need to create a custom component for that cell), yet the TableListBoxModel doesn’t have a way to inform its TableListBox.
I’ve thought about adding a “setOwner” or something like that, to the model, so that it can “call back” and update the view, yet that defeats the purpose of the MVC design. I guess that the main issue is that the model is getting the click messages, instead of the view (well, in fact is the row that gets the message and then calls down to the model, but the proper solution would mean that I subclass the RowComponent, implement the mousUp method and perform the update right there. Doing this would mean I also have to implement a custom TableListBox which deals with / and creates my custom RowComponent instead of the default one. I find this solution way too complicated for such a simple (and perhaps common?) need.
Any suggestions? Any easier approaches?
I don’t think this method interferes with the MVC approach. Really the TableListBoxModel is your controller, the TableListBox is your view and your model should be held by your controller. I normally use a ValueTree for the model but it could be anything, the Juce Demo uses some Xml. The setOwner approach or even passing a reference to the constructor is also fine, whatever suits you best and if you will be changing models to your view or not.
I suppose if you wanted a really clean, top down approach your controller (TableListBoxModel) could create and return an instance of TableListBox with itself set as the model. To follow the MVC approach you really just want to avoid the view having direct access to the model which is perfectly implemented with the controller interface.
Sorry if this doesn’t sound quite right, its very late here. Basically I think your current solution is good.
Thanks Dave. The reason why I didn’t like the Model to have a reference to the view is because that defeats the possibility of having multiple views for a given model. I’ve decided to implement something similar to the “Button listener” where I can “register” as many as needed to receive the update notification when the model changes. That said, I still find weird that it is the model that receives the “cellClicked” message, instead of the TableLIstBox, which should react to the click and then inform the model.
+1 to that, having a backward dependency is terrible and makes refactoring difficult.
Ah right, yeh if you need multiple tables controlling the same model a listener interface is probably best. Its probably the cleanest approach generally actually, maybe you could share your results with Jules and it might make it into the codebase.
The TableListBox will receive some kind of internal clicked callback but as the TableListBox doesn’t know about the model it has to inform the controller that some user interaction has occurred and then its up to the controller to change the model how it sees fit and then update the view to reflect these changes. This is all straightforward MVC, just the names don’t really reflect that paradigm. I guess something more appropriate would be TableListBoxController than TableListBoxModel but they imply the same thing.
Glad you got it sorted.