Join forces

Hi all,

I'm creating ShoreComponents layout for Magritte and I see some
compatibility problems that originate from differences between common
Seaside components and ShoreComponents. I have solved it but it also
ment to create the modified stand-alone copy of all classes in
Magritte-Seaside. This is not good way to go.

I think that we should look at current Seaside, Magritte,
ShoreComponents and other projects and find a way how to increase code
reusability. Conceive it as optional modules of one big framework that
together with persistency model can bring more easy way how to create
Seaside applications.

Traits may be the good answer on some issues but we don't want to
break VW compatibility.

Any suggestions and comments?

-- Pavel
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> I think that we should look at current Seaside, Magritte,
> ShoreComponents and other projects and find a way how to increase code
> reusability. Conceive it as optional modules of one big framework that
> together with persistency model can bring more easy way how to create
> Seaside applications.

Have a look at:
http://mc.lukas-renggli.ch/magritteaddons.html
http://mc.lukas-renggli.ch/pieraddons.html

There you can find components, structures, descriptions that integrate
into Pier/Magritte.

> Traits may be the good answer on some issues but we don't want to
> break VW compatibility.

You can just flat the classes. As long as the development happens in
Squeak this is no problem.

Philippe
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 28 août 06, at 14:40, Pavel Krivanek wrote:

PLEASE DO!!!
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.


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 8/29/06, stephane ducasse <[hidden email]> wrote:
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.

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.

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.

-- Pavel
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2006/8/29, Pavel Krivanek <[hidden email]>:
Magritte-Model-lr.224 and Magritte-Seaside-lr.192, add _zero_
overrides,  class extensions or constructors to Seaside. MAComponent
is basically a small collection of convenience methods. The added
concept of abstractness affects only the creation of subclasses and is
not needed to integrate into Magritte. Magritte plays well together
with standard seaside components that are not subcomponents of
MAComponent. Same goes the other way around, you can use Magritte
components anywhere standard seaside components work.

The only "conflicts" are #description and #asComponent. If you want to
use these (describe your components with Magritte), you need Magritte
specific code anyway.

Philippe
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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.

> 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.

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? ;-)

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> More of a problem for Magritte is that it was using the
> selectors #description and #asComponent for different things
> than recently introduced by Seaside.
> Cheers,
> Lukas

#description is a problem beyond Seaside, I still think this selector is far
to general to be in the framework.  Not being able to have #description as
an accessor on domain objects I find a huge pain.  

#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.  

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.

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 8/29/06, Philippe Marschall <[hidden email]> wrote:
> Magritte-Model-lr.224 and Magritte-Seaside-lr.192, add _zero_
> overrides,  class extensions or constructors to Seaside.

I was talking about MAComponent class>>new. That seems to be the main
reason why methods in MAComponent aren't simple additions to
WAComponent.

I think we need reusable components and extend them with Magritte
behaviour and do not create Magritte specific components. Of course I
don't mean it absolutely.

-- Pavel
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> #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
namespaces.

> 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?

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 8/29/06, Lukas Renggli <[hidden email]> wrote:
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.

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
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> 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 namespaces.

I'm guessing because you aren't American, here, #description is very common,
I can hardly think of anything more common other than #name.

> 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.

Well, not being able to use domain objects with Magritte, I consider a big
problem.  Easily bypassed by providing an override to asComponent to build
descriptions differently.

> 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.

Yes, I liked this, WAComponents should be able to be models, what good is a
widget if it can't have it's settings configured.

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

Honestly, I don't disagree that description was a good name for what
Magritte is doing, it's just that it's too common, collisions are going to
happen often.  #description is a collection, at least it responds to the
protocol, maybe simply pluralizing the selector, since it is a collection of
description objects.

anObject descriptions

While #description is common, I don't recall ever using #descriptions on a
domain object.

Or, hmm, thinking out loud...

anObject descriptor
anObject definition
anObject representation
anObject specification
anObject type

All of these seem rather uncommon to me, at least as "simple" fields on
common domain objects and still kind of jive with what Magritte is doing.
#type is even in other languages what #class is in Smalltalk, would have
good synergy with #class, which is what you were shooting for.

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> I was talking about MAComponent class>>new. That seems to be
> the main reason why methods in MAComponent aren't simple
> additions to WAComponent.
>
> I think we need reusable components and extend them with
> Magritte behaviour and do not create Magritte specific
> components. Of course I don't mean it absolutely.

MAComponent isn't necessary, you can use Magritte fine without it as long as
you fix #description on your own WAComponent base class.  Everything else in
MAComonent is for convenience.

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Have you considered forgetting about forms.  Components don't need to know
what form they're in for them to work.  When I throw a page together, I want
components, I'll put the form around them myself.  

By tying the form to the component, you're forcing them to need to know
about parents rather than letting the developer worry about this.  Without
the form stuff, ShoreComponents could just be ordinary Seaside components,
could they not?




_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Exactly. I like #type because of its shortness, though a description
is not really the same as a type. #definition seems to be rather
common in the Smalltalk Behavior hierarchy, as well it is heavily used
in Monticello and OmniBrowser. I like #descriptor, but again it is
used by OmniBrowser.

Thanks,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> Exactly. I like #type because of its shortness, though a
> description is not really the same as a type. #definition
> seems to be rather common in the Smalltalk Behavior
> hierarchy, as well it is heavily used in Monticello and
> OmniBrowser. I like #descriptor, but again it is used by OmniBrowser.
>
> Thanks,
> Lukas

Just looking in my image, there's a ton of classes using #description, and
it's pretty much always a string, which is what I'd expect, and the same
reason I want to use it as such.  Any time I see the word description, my
expectation is a string describing the object in question.  Even the
WAStoreItem from Seaside's demo store uses it, something that'd scream to be
used as a model in Magritte.


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2006/8/29, Pavel Krivanek <[hidden email]>:
> On 8/29/06, Philippe Marschall <[hidden email]> wrote:
> > Magritte-Model-lr.224 and Magritte-Seaside-lr.192, add _zero_
> > overrides,  class extensions or constructors to Seaside.
>
> I was talking about MAComponent class>>new. That seems to be the main
> reason why methods in MAComponent aren't simple additions to
> WAComponent.

This only affects MAComponent subclasses. Magritte expects classes
only to implement #new in such a way that they return an instance or
throw an exception. This is certainly true for standard Seaside
components. So this does in no way affect interoperability of
MAComponent subclasses and Seaside components.

> I think we need reusable components and extend them with Magritte
> behaviour and do not create Magritte specific components. Of course I
> don't mean it absolutely.

I agree. An example of what I mean:
A generic time chooser component Seaside component. We can then build
a Magritte component that uses this seaside component. This way
anybody can use it and there's only very little additional effort on
the Magritte side.

In general I see very limited use to describe Seaside components with
Magritte because you don't configure them dynamically in general.
(there are some nice Pier examples where this makes sense)

Philippe
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Aug 29, 2006, at 6:04 PM, Lukas Renggli wrote:

> I like #descriptor, but again it is used by OmniBrowser.

My first thought, when I read that was, "it is?"

So I went and looked, and sure enough, OBColumn implements  
#descriptor. But it's hardly an important selector. It's just there  
to factor some conditionals out of #printOn:, no big deal. I'll  
change it if that makes your life easier with Magritte.

Colin
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Besides, is Magritte likely to collide with OBColumn?  If not, who cares,
use #descriptor in Magritte, it's a much better choice than #description,
and even implies an object rather than a string, it's perfect.

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> > > I like #descriptor, but again it is used by OmniBrowser.
> >
> > My first thought, when I read that was, "it is?"
> >
> > So I went and looked, and sure enough, OBColumn implements
> > #descriptor. But it's hardly an important selector. It's just
> > there to factor some conditionals out of #printOn:, no big
> > deal. I'll change it if that makes your life easier with Magritte.

No problem, I was just checking the implementors of the suggested
selectors. I didn't look at the details though ;-)

> Besides, is Magritte likely to collide with OBColumn?  If not, who cares,
> use #descriptor in Magritte, it's a much better choice than #description,
> and even implies an object rather than a string, it's perfect.

They might collide, yes. Probably not in OBColum, but if it was used in OBNode.

OmniBrowser is an excellent tool to browse described models and their
descriptions.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Ramon Leon wrote:
>>Exactly. I like #type because of its shortness, though a
>>description is not really the same as a type. #definition
>>seems to be rather common in the Smalltalk Behavior
>>hierarchy, as well it is heavily used in Monticello and
>>OmniBrowser. I like #descriptor, but again it is used by OmniBrowser.
>>
>>Thanks,
>>Lukas

More thinking out loud ...

anObject class

anObject classDescriptor
anObject classDescription

kind of implies more info about the class, neither an existing selector
in my image, surprisingly, and highly unlikely in a domain object.

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside