There was a lively discussion on the ALT.NET mailing list about composite views when doing Model-View-Presenter, and how the sub-views get exposed. I shared my view (no pun intended) on the different strategies you might employ for sub-views.
Generally speaking, when doing Model-View-Presenter, the view is the thing that is addressable from the outside world. For example, when doing MVP with WebForms, the URL that you issue GET and POST requests against usually resolves to a View (in this case, a .aspx page). Of course, in Separated Presentation (which MVP is one form of), we want our views to be as dumb as is reasonable. Since the View is the addressable element, we often say that the Presenter is an "implementation detail" of the View. This means that the outside world is interacting with the View, and the view forwards those details onto the Presenter to do with what it will.
Many View engines support the idea of sub-Views. In WebForms, for instance, this takes the form of both User and Server Controls. A View (especially a top level View like a Page in WebForms) is usually a Composite View.
How are sub-Views handled with Model-View-Presenter? The answer probably depends on what form of MVP you're doing.
Sub-Views in Supervising Controller
Supervising Controller is the probably the more common form of MVP. The Presenter acts as an intermediary between the Model and the View, and the View contains some logic which breaks apart Model elements and places them into UI pieces on the screen.
The easiest approach to supporting sub-views has the Composite View delegating to the sub-Views without its Presenter's knowledge. As far as the Presenter is concerned, the Composite View is the only view. It passes the data into the View, and the View does with it whatever is necessary.
Most ASP.NET WebForms apps already do this, but it's not a conscious activity. Each one of those controls that you're using is a View, whether it has a Presenter or not. In fact, you don't know whether they're implemented with MVP or not, because the Presenter is, as it should be, an implementation detail. The View offers an API to you, and you use it, and trust it to do the necessary work.
When you start thinking about writing your own sub-Views, it's natural to fall into this pattern, because it's generally how the system is designed to work. The only difference is, you know there is a Presenter behind the View, just because you wrote them both. Refactoring will often lead you into this delegation pattern as well, because you're only changing the View, and not the underlying Presenter.
On the web, the main difference between your top-level View and sub-Views will often be the way you get data. On the web, the top-level View gets data from the HTTP request (URL, query parameters, form data, etc.), but sub-Views often get direct data from their consumers (strings, structured objects, etc.).
For GUI applications, there's often no difference in the way data passes between top-level Views and sub-Views, since there isn't an outside-world mechanism like HTTP.
Alternative Style: Expose Sub-Views
Although I personally prefer the approach outlined above, one alternative would be to expose your sub-Views directly off of the Composite View. When practicing MVP, most people create an interface for the View which the Presenter talks to. The Composite View can expose these view interfaces directly to its Presenter, and allow the Presenter to talk directly to the sub-Views. In turn, those sub-Views will pass on their data to their own Presenter.
The benefit here is that you may be able to factor out common Presenter behavior and actually create Composite Presenters to go along with your Composite Views, as a way of achieving DRY. The downside, though, is that you've created a tighter coupling; not only is the Presenter for the Composite View aware of that View, but also of all the sub-Views that it uses. This has the effect of reducing the refactorability of the code.
Sub-Views in Passive View
Passive View style MVP is less common than Supervising Controller, although it is the style I personally prefer. The idea behind Passive View is to eliminate all code from the View, even code that would normally have been responsible for breaking apart model data and placing onto the screen.
In this style of MVP, the View is essentially directly always exposing all sub-Views, and the Presenter is directly setting values into the Views (and subscribing to notifications from them).
A sub-View here usually ends up getting re-exposed by the Composite View. For example, if you had an address editor on screen, you would probably expose text boxes for the 2 lines of address, the city, the state, and the postal code. While these things may be represented as a sub-View, their individual elements are re-exposed by the Composite View as though they were on the Composite View itself. When you re-use the sub-View (say, to edit both a shipping address as well as a billing address), the Presenter is still directly exposed all the text boxes, though they may now have names like ShippingAddress1, ShippingAddress2, BillingAddress1, BillingAddress2, etc.
