Smalltalk › Frameworks & Tools › Seaside › Seaside General

Seaside Components: Parent / Children

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

16 messages Options

Sébastien Julliand

Seaside Components: Parent / Children

Hi everyone!

I'm one of S. Ducasse's student and I'm working on a Seaside project,
an online Scrabble.

I'd like to know if there is a way, when you are using a WAComponent
called by a WATask, to retrieve the caller?
In other words: is a WAComponent able to identify who is calling it?
Thanks in advance for your answers!

Best regards,

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

Avi Bryant

Re: Seaside Components: Parent / Children

On May 15, 2006, at 5:01 PM, Sébastien Julliand wrote:

> Hi everyone!
>
> I'm one of S. Ducasse's student and I'm working on a Seaside project,
> an online Scrabble.
>
> I'd like to know if there is a way, when you are using a WAComponent
> called by a WATask, to retrieve the caller?
> In other words: is a WAComponent able to identify who is calling it?

So, obvious first question: why do you want to know?

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

Sébastien Julliand

Re: Seaside Components: Parent / Children

2006/5/15, Avi Bryant <[hidden email]>:

>
> On May 15, 2006, at 5:01 PM, Sébastien Julliand wrote:
>
> > Hi everyone!
> >
> > I'm one of S. Ducasse's student and I'm working on a Seaside project,
> > an online Scrabble.
> >
> > I'd like to know if there is a way, when you are using a WAComponent
> > called by a WATask, to retrieve the caller?
> > In other words: is a WAComponent able to identify who is calling it?
>
> So, obvious first question: why do you want to know?
>
> Avi_______________________________________________

Well, I need my WAComponent to display differents things based on wich
WATask is calling it (the component displays a Scrabble board, wich is
shared between the two players and a control panel wich is not). For
example, at a given time, player 1 needs to see the board and his
control panel and player 2 needs to see the board and a "disabled"
control panel. And then, according to what i've done so far, if i
could know who is calling the component, it would be great ;)

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

Avi Bryant

Re: Seaside Components: Parent / Children

On May 15, 2006, at 5:39 PM, Sébastien Julliand wrote:

> 2006/5/15, Avi Bryant <[hidden email]>:
>>
>> On May 15, 2006, at 5:01 PM, Sébastien Julliand wrote:
>>
>> > Hi everyone!
>> >
>> > I'm one of S. Ducasse's student and I'm working on a Seaside
>> project,
>> > an online Scrabble.
>> >
>> > I'd like to know if there is a way, when you are using a
>> WAComponent
>> > called by a WATask, to retrieve the caller?
>> > In other words: is a WAComponent able to identify who is calling
>> it?
>>
>> So, obvious first question: why do you want to know?
>>
>> Avi_______________________________________________
>
> Well, I need my WAComponent to display differents things based on wich
> WATask is calling it

So why not have the different WATasks configure the WAComponent they
are creating slightly differently?
I'm generally quite suspicious of code that knows too much implicit
info about the context in which it is used.

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

Sébastien Julliand

Re: Seaside Components: Parent / Children

2006/5/15, Avi Bryant <[hidden email]>:

>
> On May 15, 2006, at 5:39 PM, Sébastien Julliand wrote:
>
> > 2006/5/15, Avi Bryant <[hidden email]>:
> >>
> >> On May 15, 2006, at 5:01 PM, Sébastien Julliand wrote:
> >>
> >> > Hi everyone!
> >> >
> >> > I'm one of S. Ducasse's student and I'm working on a Seaside
> >> project,
> >> > an online Scrabble.
> >> >
> >> > I'd like to know if there is a way, when you are using a
> >> WAComponent
> >> > called by a WATask, to retrieve the caller?
> >> > In other words: is a WAComponent able to identify who is calling
> >> it?
> >>
> >> So, obvious first question: why do you want to know?
> >>
> >> Avi_______________________________________________
> >
> > Well, I need my WAComponent to display differents things based on wich
> > WATask is calling it
>
> So why not have the different WATasks configure the WAComponent they
> are creating slightly differently?
> I'm generally quite suspicious of code that knows too much implicit
> info about the context in which it is used.
>

That's a good point. I'll try to do something with the "clone" method
since my WAComponents aren't created at the same time and as you say
they are just slightly different.
Thanks for your advice!

Seb, back to work :)
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Sebastien Genier [M1 ETSIE]

CSS problem for IE

Hi,

I'm a student of S. Ducasse and I'm working on a Seaside project : RSS feeds
reading, to create a small webpage like live.com.

I have problems with my style method in Squeak. Generally, I use '_' to
write my CSS for Internet Explorer.

For example I use
Padding: 5px;
_padding: 5px; //for IE

But I can't tape '_' in Squeak.

An other question (it concern more CSS than Seaside specialy, sorry...) :
I have a link anchorWithAction and I've put inside a level 2
heading.
In my style method, I use h2:hover to specify the style of my title
when the mouse goes over it.
This method works on firefox but not on IE...

Thank you per advance for your answers, then I'll begin ajax programming :)

Think about the +1 mister Ducasse ^^

Sébastien GENIER
Technology and Management MS Degree (1st year)
Institute of Management - University of Savoie
Speciality ETSIE
[hidden email]

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

Colin Putney

Re: Seaside Components: Parent / Children

In reply to this post by Avi Bryant

On May 15, 2006, at 11:42 AM, Avi Bryant wrote:

> So why not have the different WATasks configure the WAComponent
> they are creating slightly differently?
> I'm generally quite suspicious of code that knows too much implicit
> info about the context in which it is used.

Indeed, the whole point of call/answer is so that components don't
have to know about their context.

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

Ramon Leon

RE: Seaside Components: Parent / Children

In reply to this post by Sébastien Julliand

> From: [hidden email]
> [mailto:[hidden email]] On Behalf
> Of Colin Putney
> Sent: Monday, May 15, 2006 1:50 PM
> To: The Squeak Enterprise Aubergines Server - general discussion.
> Subject: Re: [Seaside] Seaside Components: Parent / Children
>
>
> On May 15, 2006, at 11:42 AM, Avi Bryant wrote:
>
> > So why not have the different WATasks configure the
> WAComponent they
> > are creating slightly differently?
> > I'm generally quite suspicious of code that knows too much implicit
> > info about the context in which it is used.
>
> Indeed, the whole point of call/answer is so that components
> don't have to know about their context.
>
> Colin

Too true, this seems to be a common thing when learning objects, trying
to make them too smart and reaching out to fetch the data they should
have been constructed with in the first place.
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Zulq Alam

Re: Seaside Components: Parent / Children

In reply to this post by Avi Bryant

Avi Bryant wrote:
>
> So why not have the different WATasks configure the WAComponent they
> are creating slightly differently?
> I'm generally quite suspicious of code that knows too much implicit
> info about the context in which it is used.
>

In one direction or another the components will be coupled (parent
configuring child or child reacting to parent) so why is one direction
better than the other?

It seems to me both are valid?

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

Ramon Leon

RE: Seaside Components: Parent / Children

In reply to this post by Sébastien Julliand

> Avi Bryant wrote:
> >
> > So why not have the different WATasks configure the
> WAComponent they
> > are creating slightly differently?
> > I'm generally quite suspicious of code that knows too much implicit
> > info about the context in which it is used.
> >
>
> In one direction or another the components will be coupled
> (parent configuring child or child reacting to parent) so why
> is one direction better than the other?
>
> It seems to me both are valid?
>
> - Zulq

When the parent does the configuring of the child, the component is
loosely coupled and reusable, it can have many parents, the reverse is
not true. A child component that knows about it's parent, is usually
limited to only work when used with that parent, tightly coupled, and
not reusable.
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Sebastián Sastre

RE: Seaside Components: Parent / Children

Yes but that depends of *how much* it knows about it's parent. For certain
features this could be really helpful. Abuse produce the results you
mention.
For a reference:
Presenters are composed by (sub)Presenters and they all know it's
corresponding #parentPresenter in the MPV (Model-View-Presenter) framework.
Ref:
http://www.object-arts.com/Papers/TwistingTheTriad.PDF
http://www.mimuw.edu.pl/~sl/teaching/00_01/Delfin_EC/Overviews/ModelViewPres
enter.htm

I've made my own WAPresenter subclass wich is instantiated knowing about it
parentPresenter. I see the same intention in

ShoreComponent class>>parent: aComponent

Until now I have been succeful in a Seaside application that make intesively
use of that subclasses, without coupling.

Regards,

Sebastian

> -----Mensaje original-----
> De: [hidden email]
> [mailto:[hidden email]] En nombre
> de Ramon Leon
> Enviado el: Martes, 16 de Mayo de 2006 13:07
> Para: The Squeak Enterprise Aubergines Server - general discussion.
> Asunto: RE: [Seaside] Seaside Components: Parent / Children
>
> > Avi Bryant wrote:
> > >
> > > So why not have the different WATasks configure the
> > WAComponent they
> > > are creating slightly differently?
> > > I'm generally quite suspicious of code that knows too
> much implicit
> > > info about the context in which it is used.
> > >
> >
> > In one direction or another the components will be coupled (parent
> > configuring child or child reacting to parent) so why is
> one direction
> > better than the other?
> >
> > It seems to me both are valid?
> >
> > - Zulq
>
> When the parent does the configuring of the child, the
> component is loosely coupled and reusable, it can have many
> parents, the reverse is not true. A child component that
> knows about it's parent, is usually limited to only work when
> used with that parent, tightly coupled, and not reusable.
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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

Ramon Leon

RE: Seaside Components: Parent / Children

In reply to this post by Sébastien Julliand

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf
> Of Sebastián Sastre
> Sent: Tuesday, May 16, 2006 9:36 AM
> To: 'The Squeak Enterprise Aubergines Server - general discussion.'
> Subject: RE: [Seaside] Seaside Components: Parent / Children
>
> Yes but that depends of *how much* it knows about it's
> parent. For certain features this could be really helpful.
> Abuse produce the results you mention.
> For a reference:
> Presenters are composed by (sub)Presenters and they all know
> it's corresponding #parentPresenter in the MPV
> (Model-View-Presenter) framework.
> Ref:
> http://www.object-arts.com/Papers/TwistingTheTriad.PDF
> http://www.mimuw.edu.pl/~sl/teaching/00_01/Delfin_EC/Overviews
> /ModelViewPres
> enter.htm
>
> I've made my own WAPresenter subclass wich is instantiated
> knowing about it parentPresenter. I see the same intention in
>
> ShoreComponent class>>parent: aComponent
>
> Until now I have been succeful in a Seaside application that
> make intesively use of that subclasses, without coupling.
>
> Regards,
>
> Sebastian

Sure, it's not a problem knowing about or accessing the parent, if all parents can be treated the same, and it's often quite useful. It's when a child has knowledge of a specific parent that the problems begin.
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Chris Muller

Re: Seaside Components: Parent / Children

In reply to this post by Sébastien Julliand

> In one direction or another the components will be coupled (parent
> configuring child or child reacting to parent) so why is one
> direction
> better than the other?

To enable reusability.

You want coupling from the specific to the general, never from the
general to the specific.

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

Ramon Leon

RE: Seaside Components: Parent / Children

In reply to this post by Sébastien Julliand

>
> > In one direction or another the components will be coupled (parent
> > configuring child or child reacting to parent) so why is
> one direction
> > better than the other?
>
> To enable reusability.
>
> You want coupling from the specific to the general, never
> from the general to the specific.
>

Heh.. You almost sounded like Rob Martin talking about dependency
inversion there...
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Sebastián Sastre

RE: Seaside Components: Parent / Children

In reply to this post by Ramon Leon

>
> Sure, it's not a problem knowing about or accessing the
> parent, if all parents can be treated the same, and it's
> often quite useful. It's when a child has knowledge of a
> specific parent that the problems begin.

Totally agree. In fact I think what Chris Muller has said is the point

"...You want coupling from the specific to the general, never from the
general to the specific..."

Sebastian

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

Zulq Alam

Re: Seaside Components: Parent / Children

In reply to this post by Chris Muller

> To enable reusability.
>
> You want coupling from the specific to the general, never from the
> general to the specific.
>

So you have N components each with code calling/constructing a component
X in a variety of ways to get X to behave differently.

If we need to change how X is called (e.g. with more/different
information) we have to change the N components.

If you have X react differently based on the properties of the caller
(any of N) then a change to X is just a change to X assuming N provides
access to these properties.

If X needs new/different properties from N then you add methods to N
that are likely usable in a more general context. A change to N but a
change that is about N and not about X.

Furthermore, X could be made tolerant of different Ns using #respondsTo.

I'm not advocating using one direction over the other. I think both have
their advantages and disadvantages and in most cases this isn't even an
issue, i.e. the number of N is very small (similar specificities).

It's late and I may be spouting rubbish, let me know if I am... ;-)

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