[Seaside] Join forces

[Pavel Krivanek]

On 8/29/06, Lukas Renggli <renggli at gmail.com> wrote:
> > > Each time I ask people about shoreComponents they told me that they
> > > were not
> > > usable as any other seaside components and I found that sad. because
> > > we need
> > > a library of standard reusable components. So what you are doing is
> > > important.
> >
> > Yes, this was the most painful decision during desing of
> > ShoreComponents. But the changes had IMHO very good reasons and they
> > were done for better reusability of this components. The main change
> > is adding of obligatory parent reference that enables to control the
> > components hierarchy, use embedded forms etc.
>
> In my opinion it is exactly this parent reference that makes them
> *less* reusable. It creates a strong coupling in the component
> hierarchy and turns them unuseable in any other context/framework not
> following that pattern.

I was talking about another kind of reusablity. I know that it breaks
the compatibility with another components (but using common Seaside
components in ShoreComponents applications is possible) and that's the
main reason why I started this discussion.

Some examples where this increases the reusability:
- it enables to use embedded forms. That means that if you design
components, you can use form tag everywhere where you need (with some
little limitations) and you don't have to think about relationship to
next components
- you can very simply specify where for example where the standard
dialogs (inform:..) will be placed and this information is not
directly assigned to the component. It is specified independently in
the components hierarchy.
- you have simple access to some important hierarchy elements (root,
header etc.)

I don't tell that the parent reference is the only solution but it
seems the most powerful and clean to me (now). I'm ready do redesign
my components but I have to see that it will be the step forward.

> > The big problem is that every bigger set of components use own basic
> > component class - and the main motivation is to do not break the old
> > code. ShoreComponents adds parent reference and attributes and
> > overrides constructors, Magritte overrides constructors etc.
>
> It is good practice to always call "super initialize" if you override
> the instance side of #initialize. Even SmallLint points that out, if
> you miss it. If you follow that pattern (Magritte does) it should be
> no problem to have full reuse.

Of course I always do it. But as far as I remember, I had to remove it
somewhere in ShoreComponents because of VW compatibility but I'm not
sure now.

> More of a problem for Magritte is that it was using the selectors
> #description and #asComponent for different things than recently
> introduced by Seaside.
>
> > So we should find another approach that will help us to use one
> > extensible basic class for all this projects with stable protocol.
> > Maybe some handy design pattern for that.
>
> Class extensions?
> Instance-variable extensions? ;-)

Some mechanism that enables us to have for example some nice
component(s) for date picker that can be optionally enhanced with
Magritte etc. So somebody can focus on developing the component and
somebody on the meta-description etc. Something like adding new parent
slot to a Self object.

-- Pavel