On Mon, 16 Jun 2003, Paul Mitchell-Gears wrote:

Class WADialog gives you basic Dialog behaviour. It seems to me that I might like to subclass this in two orthogonal directions: either (1) to give different look'n'feels, ie by overriding #renderContentOn, or (2) to give extra behaviour on top of the standard Dialog (ie build something more complex, that also IS-A Dialog).

I have the feeling that (2) is the 'real' inheritance tree here. Which suggests to me that perhaps the variation allowed by (1), which is also necessary, should be modelled by delegation rather than inheritance.

But what would this look like? It might look like a separate View class per Controller. But I seem to remember reading somewhere on this list that you deliberately decided to merge the V and C of MVC into seaside's 'Component' concept.

Paul,

These are interesting issues, and certainly ones that I don't feel I have a firm grasp on, so it's great to be discussing them. A few comments:

- The general model I've been trying to advocate is that look+feel changes happen through CSS, not through HTML generation. To that end, I've been writing components with minimal markup and lots of css class/id info. They can then be used in lots of different applications, each of which provides its own stylesheet to customize their look.

It's quite surprising how much can be achieved with CSS; I was recently shown http://csszengarden.com/, which includes tens of wildly different looks for the exact same HTML.

- Depending on how you want to extend the behavior of Dialog, embedding may be an option. In general, I lean towards composing lots of small components, rather than subclassing large ones. That would leave inheritance open for points on the look+feel axis that can't be covered by CSS (for example, if you wanted to use links instead of form buttons).

- There's nothing stopping you from having a separate view object that the component delegates to. Just have, say,

renderContentOn: html html render: (self viewClass new controller: self)

viewClass: aClass viewClass := aClass

viewClass ^ viewClass ifNil: [MyDefaultViewClass]

I would strongly encourage people to experiment with designs like this; if we find that a more explicit view/controller separation works out well, maybe we'll want to move the framework formally in that direction in a later version. I think things are flexible enough right now that nothing should get in the way of trying this. (If you were going to set something like this up, you might want to look at subclassing from Controller directly, instead of Component, since the various rendering methods that Component adds wouldn't be used).

Anyone else have thoughts here?

Avi