[Twisted-web] Trouble chaining Javascript module calls in Athena (example code attached).

Jean-Paul Calderone 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:

Sure.

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

>
>3. However, whereas server->client calls have implicit access to the Athena
>Id, so the callRemote() can be routed accordingly to the right instance,
>client-side Javascript doesn't have this.

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
>object disambiguation.
>
>If this is the case, then I need a way of informing *client* side objects how
>to find each other. In other words, I need to embed the callee javascript
>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
>> modules.
>
>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' );

Yep.

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

Jean-Paul



More information about the Twisted-web mailing list