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

Tim Rowledge tim@sumeru.stanford.edu
Sun, 12 May 2002 23:33:45 -0700

In message <Pine.LNX.4.30.0205122022080.7250-100000@cable.beta4.com>
          Avi Bryant <avi@beta4.com> wrote:

> 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?
'internally' as in "the method is correctly called and can set the
instvar 'currentQuestion' and do a Transcript show: of the value
passed".  The browser does it's little redisplay shimmy but the contents
of the questionPane stays the same, no matter what appears in the
Transcript; I've used inspect to see that the system really does think
the value of currentQuestion is changed.
Ah-hah. I changed
QuestionPage>html to
^question description
and it now updates appropriately. Duh?

> > 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.
Sort of mumbling to myself, possibly to the benefit of others
'listening' and having similar problems. Basically I wanted to convince
myself that the binding worked using messages instead of
evil-webobject-instvar-raping. One of the reasons I dislike having
methods that share a name with an instvar is that it allows confusion
when explaining stuff.

> > 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.
Somebody (may as well be the test presenting page unless we can think
of something better) needs to get back a true or false to allow tracking
the score. Obviously at some point I need to know about the user, load
their records, store the score, all that crap.

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

> - path bindings.  These are used to keep attributes of the child elements
> in sync with attributes of the parent.  For example,
>   parent bar: (child x)
> after every request.
By 'after every request' I guess you mean after the stuff done by the
child has completed and returned?
> 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?
A little - but the crucial confusion I'm suffering right now is how that
is invoked. In fact I'm a bit puzzled about what invokes any of
the bindings. For example, I have the #question binding on the
questionPage element and it makes reasonable sense now; but nowhere that
I can see have I done anything to invoke it; my questionPage #html is
nothing more than the text of the question right now.
Are all the bindings invoked on every display? If so, in what order?

The only invokation I can think of that makes sense would be something
<li .....
<a sea:id="onAnswer:">Answer</a>'
but I dont see where the argument for #onAnswer: would come from.


Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim
The whole is the sum of its parts, plus one or more bugs