On Wed, 30 May 2007 12:58:48 +0300, kgi <[EMAIL PROTECTED]> wrote:
On Wednesday 30 May 2007 02:25:23 Jean-Paul Calderone wrote:
On Wed, 30 May 2007 01:44:07 +0300, kgi <[EMAIL PROTECTED]> 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
_______________________________________________
Twisted-web mailing list
[email protected]
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
