(example code attached).
exarkun at divmod.com
Wed May 30 08:15:56 EDT 2007
On Wed, 30 May 2007 12:58:48 +0300, kgi <iacovou at gmail.com> wrote:
>On Wednesday 30 May 2007 02:25:23 Jean-Paul Calderone wrote:
>> On Wed, 30 May 2007 01:44:07 +0300, kgi <iacovou at gmail.com> wrote:
>Hi Jean-Paul; thanks yet again for chiming in with a timely response.
>> This is like trying to call an unbound method in Python. What you really
>> want to be doing is calling chain on an /instance/ of XCall.B, not on the
>> class object itself.
>I see what you mean. I *thought* I was just mimicking the approach used in
>lots of the Nevow code itself, but now I see The Error Of My Ways. Just to
>make sure that my insight is not bogus, can you comment on the "truthiness"
>of the following statements:
>1. When a LiveElement is rendered, it is assigned an Athena Id (probably
>server-side) and something in the Nevow runtime creates a class *instance*,
>identifiable and accessible from the server through the magic of the Athena
>Id. In other words, there is rarely (never?) direct instantiation in JS code
>of objects ("var f = new Foo()") when the classes are Athena subclasses.
Yep. To be specific, "Nevow.Athena.Widget subclasses", though I don't think there are any other interested classes in the Nevow.Athena namespace. ;)
>2. If I instantiated N LiveElements of the same class, all N would be
>individually accessible from the server just by calling object.callRemote().
Right. Each server-side LiveElement instance is tangled up with its
corresponding client-side Nevow.Athena.Widget (subclass) instance, and
>3. However, whereas server->client calls have implicit access to the Athena
>Id, so the callRemote() can be routed accordingly to the right instance,
Roughly correct, but see below.
>I think I was confused by the fact that up until now I've only been having one
>LiveElement instance of each type on a page, so I never had to think about
>If this is the case, then I need a way of informing *client* side objects how
>object's Athena Id into the caller, either at creation time, or later. Is
>this a "done thing"?
>(Either that, or I go via the server)
Widgets on the client have a hierarchical relationship with each other which
reflects the hierarchical relationship of their corresponding server-side
LiveElement progenitors. That is, if LiveElement B has setFragmentParent
called on it with LiveElement A as an argument, then Widget B will have a
widgetParent property which refers to Widget A; similarly, Widget A's
childWidgets array property will include widget B. These relationships
can be used to pass messages between widgets in the browser without
involving the server.
>> Also, I'd recommend not clobbering XCall.A and XCall.B with your class
>> objects, since those are set up to be module objects because they each
>> have a corresponding .js file. Athena's module system tries to mimick
>> many aspects of Python's - in this case, XCall corresponds to a package,
>> XCall.A and XCall.B are modules in that package, and you want to be
>> defining things like XCall.A.Foo and XCall.B.Bar as attributes of those
>Ah, I see. You mean that the very existence of the files XCall/A.js sets up
>the (empty?) XCall.A namespace, and within XCall.A.js I define classes like:
> XCall.A.Foo = Nevow.Athena.Widget.subclass ( 'XCall.A.Foo' );
>Thanks again for your help, Jean-Paul, I know how busy you guys are. I'm sorry
>if it takes two or three attempts to get my head round some of the muddier
>aspects of how it all fits together - it's all pretty new and unfamiliar.
No problem. :) Hope this helps,
More information about the Twisted-web