[Twisted-web] Quick Questions about JS mapping in Athena.

kgi iacovou at gmail.com
Thu May 17 12:29:26 EDT 2007

On Thursday 17 May 2007 18:31:59 Jean-Paul Calderone wrote:

Hi Jean-Paul; thanks for your quick answer.

> The import system requires more or less complete knowledge of what modules
> are defined in order to resolve dependencies.  If each LiveElement took
> care to declaring which file it needed, then the page would need to be
> rendered completely before Athena could figure out which modules needed to
> be loaded, by which time it is a little too late to include them in the
> page (perhaps this could be made to work, but it would be a hassle).

OK, I guess I'll just have to bite the bullet. Adding something to sys.path is 
not such a big deal.

> I wouldn't be happy to see a solution that required declaring all
> LiveElement classes a LivePage is going to use, since my own most common
> use-case for LivePages involves my not having any idea what most of the
> LiveElements will be (and in fact, changing what they will be with almost
> every render).  I'm open to other suggestions and discussion about
> improving this area of Athena, though.

Oh, really? That's interesting. How does Athena push new Javascript code to a 
page after the initial render? I didn't even know it was possible to do such 
a thing: for me, Javascript has always been something you link to from the 
page header. Looks like my 4th Edition "JS Definitive Guide" (2001) is 
showing its age :-)

> The idea is to provide a package hierarchy, as Python has.  The strings
> will be split on "." in a couple places, but if there is simply no "." in
> them, this will work (since it is equivalent to any top-level name in an
> arrangement which does use dotted names).  The goal of dotted names is to
> avoid polluting the top-level namespace more than necessary.

You're talking about Javascript's top-level namespace, right? (I assume these 
strings never go anywhere near Python's namespace). OK, that sounds logical; 
I was just wondering whether there was anything more to it that.

>  For sanity's
> sake, I would define classes in a module as attributes of that module,
> rather than using arbitrary other names

Hmm, I'm not quite sure I understand what you mean in this context. I *think* 
you're talking about JS classes, but the terminology is Python terminology.

If the former (JS classes) do you mean, you'd prefer to have a single (or a 
few) javascript file(s) and have these define the JS for *lots* of related 
LiveElement classes, which all declare themselves to be a (namespaced) 
jsClass, and all these jsClasses map to the same physical JS file?

In other words, for project "Cutlery":

# In Python LivePage stuff:

class Fork ( LiveElement ):
    jsClass = u'Cutlery.Fork'

class Spoon ( LiveElement ):
    jsClass = u'Cutlery.Spoon'

class Knife ( LiveElement ):
    jsClass = u'Cutlery.Knife'

# In Python plugin code:

jsModules.mapping = {
  # Note: the same file!
  u'Cutlery.Fork' : 'cutlery.js',
  u'Cutlery.Spoon' : 'cutlery.js',
  u'Cutlery.Knife' : 'cutlery.js',

# In the file cutlery.js:

Cutlery = {};

Cutlery.Fork = Nevow.Athena.Widget.subclass ( 'Cutlery.Fork' );
Cutlery.Fork.methods ( ... );

Cutlery.Spoon = Nevow.Athena.Widget.subclass ( 'Cutlery.Spoon' );
Cutlery.Spoon.methods ( ... );

Cutlery.Knife = Nevow.Athena.Widget.subclass ( 'Cutlery.Knife' );
Cutlery.Knife.methods ( ... );

Is this what you mean?

Actually, I have a couple more very quick questions that I thought up while 
typing this:

- Am I right in thinking that no athena JS files ever need to have declare any 
of the modules mentioned in BOOTSTRAP_MODULES (e.g. Divmod, Nevow.Athena)?

- Is there a recommended way for LiveElements to access each other on the 
server? For example, I click on an element of (client-side) Foo that invokes 
a method on (server-side) Foo; this then needs to update the state of 
(server-side) Bar, which needs to update (client-side) Bar. At the moment I'm 
using an manual ad-hoc registry, with the occasional (naughty?) 
obj.fragmentParent thrown in. I was wondering if there was a more robust 
method already in place that I had totally missed (like the LiveElements 
being assigned names upon creation, which can then be automagically found 
through something like page.findElementByName ( "Bar" )).



More information about the Twisted-web mailing list