[Seaside] using inheritance to describe look'n'feel

Avi Bryant avi at beta4.com
Mon Jun 16 14:12:05 CEST 2003


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



More information about the Seaside mailing list