[Seaside] Woohoo, made a list of links! Now for the next bit...

[Avi Bryant]

On Sun, 12 May 2002, Tim Rowledge wrote:

> OK, done all that and it seems to work internally but the browser page
> is not updated properly - ie dumping the text of the chosen question
> works but the page in the browser keeps the same text as the first time.
> Tried this on several browsers on several machines.

Not sure I understand you.  What do you mean by "internally"?  What
is actually working and what isn't?

> It mostly makes sense, but I still feel a little uncomfortable about the
> binding stuff being able to fumble around for instvar names. Feels too
> much like rape. Is there any particular reason not to keep to messages
> - especially since they work ok for setting as well as getting? Apart
> from anything else a single case is much easier to explain than a
> precedence hierarchy!

Yeah, you can probably convince me here.  The only real argument for
keeping the inst var lookup is that people used to WebObjects (from which
all this path binding stuff originated) expect it to work that way.  But I
admit that it's a divergence from the Smalltalk Way without any real
justification.

> Just to satisfy myself, I tried with the above binding as
>   set: #theQuestion toPath: 'theCurrentQuestion'
> and indeed it then needed methods implementing to work. So I conclude
> that the first argument is passed to the element and the second to
> 'self'.

I'm not sure exactly what you're doing here, but maybe it'll make more
sense if you explain it after reading what I write about bindings later in
this message.

> <td>
>   <span sea:id="currentQuestion.notNil=true">
>      <page sea:id="questionPane">
>   </span>
>   <span sea:id="currentQuestion.notNil=false">
>      <page sea:id="testDescriptionPane">
>   </span>
> </td>
> would also be considered good style? (Have you been working with this
> long enough to have developed serious style & practice opinions? )

I don't see any particular reason to break that out into a subcomponent.
The two main reasons I tend to do that are:

- I'm going to reuse the subcomponent elsewhere
- The subcomponent is taking a distinctly narrower view than its parent,
eg, it is showing a single item in a list.

> I think that the thing to do is have the question check the proffered
> response and somehow return true or false to the test handling page.

Yes, that makes sense.  I was more wondering what you do at the point that
you know whether the answer was right or wrong.

> Do I get the real oop so that simply checking it against the correct
> answer will work? i.e. if I provide an array with 'foo' 'bar' &
> 'wibble' will I get back the same 'foo' String and thereby find that
> answer == the Array at:1 ?

Yes.

> Errr.... you'll have to run that one by me again I'm afraid.  I can't
> work out what a block and set:toMethod: have to do with it. Given what
> I thought I understood from above (the second version of my
> question/theQuestion binding) I can't see why one needs anything
> different to another set:toPath:.

Ok, let me try to be a little bit clearer.  There are basically three
kinds of bindings that are commonly used.  These are:

- literal bindings.  These are used to pass constant values into elements
or subcomponents.  For example, if you were embedding an IADialog into
your page, you might use a literal binding like

(template elementNamed: 'dialog')
  class: IADialog;
  set: #message to: 'What is your name?';
  ...

You can sorta think of this as

  child message: 'What is your name?'

- path bindings.  These are used to keep attributes of the child elements
in sync with attributes of the parent.  For example,

(template elementNamed: 'foo')
  set: #x toPath: 'bar'

You can think of this as

  child x: (parent bar)

before every display of the 'foo' element.
Path bindings can also be two way:

(template elementNamed: 'foo')
  bind: #x toPath: 'bar'

which you can think of as

  child x: (parent bar)

before every response, and

  parent bar: (child x)

after every request.

- method bindings.  These are used when an element (such as a link or a
submit button) needs to invoke its parent's behavior.  For example, when
you have

<a sea:id="chooseQuestion:">,

there is an implicit binding that looks like

(template elementNamed: 'chooseQuestion:')
  set: #action toMethod: #chooseQuestion:

You can think of this as

child action: [:v | parent chooseQuestion: v].

Now, getting back to my example - I was saying you might wish to do
something like

(template elementNamed: 'questionPane')
  set: #onAnswer toMethod: #answerQuestion:

Now, this is basically

  child onAnswer: [:v | parent answerQuestion: v]

Does that make any more sense?
(Explaining all this is definitely increasing my desire to find a more
block-based alternative to bindings...)

Cheers,
Avi