I've noticed that user interface often comes to "layered MVC" (pardon me, I just came up with this new term). Let's take Swing table. It has a model (AbstractTableModel) and a view (JTable). When I use it, I do not put my business data in table model. For me both JTable and corresponding table model is only a part of my own View, which is in example a dialog. So this looks like MVC inside MVC.
Now I have a controller which contains FrameWindow and view cache object. Views are not created until requested by the user. View cache contains all created views. Like this:
I have a view which may require displaying a dialog box upon a button click. I consider this dialog a view. But there is a problem. Dialog needs to be displayed as child of FrameWnd and also positioned in center of it:
Is it nice to pass FrameWnd all the way down hierarchy? It is a controller job to display views, isn't it?
In MVC view notifies controller about user actions by firing events. I am thinking of implementing something like Chain of Responsibility pattern using events: bottom level component fires event, its parent anticipates event and if it can not solve the problem it fires his own event including cause/original event and so on until somebody takes action. That would be technicaly alike throwing exception with specified cause (new exception references previous one). Since event object contains event source, the handler of event (in my case controller) will get all objects along hierarchy path.
What do you think about this solution? Maybe there is more elegant way? While I wrote this, I thought maybe I could somehow remove this "view contains other view" thing. Still what do you think of chain of responsibility implementation using events?
I can't say I followed all of that, but Sun docs (or maybe the only Swing book I ever bought and can't find) talked about Swing using MVC internally. It sounded pretty compelling at the time. As systems are built up of subsystems it shouldn't be surprising to find recursive or repeating architectures and patterns.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Vladas your idea is quite nice and is called HMVC as already pointed by Marlene. One little correction:
It has a model (AbstractTableModel) and a view (JTable). When I use it, I do not put my business data in table model. For me both JTable and corresponding table model is only a part of my own View, which is in example a dialog.
In this case you already have the model and the view, not just the view .
ps: follow the links Marlene posted. They will give you a much clear idea.