[Seaside] Join forces

Lukas Renggli renggli at gmail.com
Tue Aug 29 21:15:50 UTC 2006

> #name and #description are probably the two most common fields in a business
> object, if I look in most of the databases around here, just about every
> table has a description column, having to map this to something else in the
> model bothers me.

Honestly, I never had a selector in any of my business applications
called #description before I implemented Magritte. I still find it a
nice selector name for what it does in my framework, though I see that
there might be better choices. The problem is however, no matter how
crazy you name your methods, there is always an environment that
conflicts, unless you have something like class-boxes or selector

> Objects don't break when I override #name and do what I want with it, as I'm
> just providing a more specific name, but #description is another story.  We
> had this conversation once, but given the incontinence it poses to a domain
> model, I still disagree with you, #description was a bad choice for a
> selector.  That its recent introduction into Seaside broke something, was
> inevitable.

Magritte does not break if you override #description or #asComponent,
you just cannot use these objects together with Magritte as simple as
the other ones. So this is not really a problem.

The problem I got in Pier, was because I used subclasses of
WAComponent as model objects with their own descriptions, etc.
Probably only very few people actually do something like this. This is
the only case the thing breaks with the latest Seaside and it can be
fixed easily.

So what are your suggestions for those two selector names for the next
version of Magritte?


Lukas Renggli

More information about the Seaside mailing list