[Twisted-web] Quick Questions about JS mapping in Athena.
exarkun at divmod.com
Thu May 17 11:31:59 EDT 2007
On Thu, 17 May 2007 17:57:35 +0300, kgi <iacovou at gmail.com> wrote:
>I have a couple of quick questions regarding JS in Athena. At least, they're
>quick to ask; I hope they're also quick to answer.
>So, my questions is: is there a way to register the JS mapping elsewhere? It
>looks like modifying self.jsModules.mapping directly inside the constructor
>of a LivePage might do it, but that feels hacky as heck.
This works, but I agree it has a hackish feel.
>As an aside: I desperately don't want to ruffle any feathers here, but I also
>feel that using the twisted plugins system to store what amounts to a
>dictionary is a bit of a sledgehammer and nut thing. Since the actual
>LiveElement classes don't even live in the same place as the mapping, it's
>not as if the athena.JSPackages are really "plugins", as they only contain
>data, not code. Wouldn't having a "jsFile" attribute directly on the
>LiveElements be more natural, since in any case, the renderer looks up
>the "jsClass" attribute and looks up the corresponding JS file in jsModules?
>Possibly in conjunction with an attribute (allElements?) on LivePage that you
>can set to pre-declare all Elements you intend to use ahead of time so all
>the JS gets included in the page in the same place).
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).
I can sympthatize somewhat with your desire to avoid conforming to the
structure required by the Twisted plugin system here, but I don't have a
better solution to suggest now. In my copious spare time, I am trying to
push something better into Twisted (plugins are really a low level thing,
not what you actually want to be interacting with), but that's not likely
to see any results for quite a while to come.
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,
>Secondly, what are the requirements on the naming of JS packages? Many of the
>examples use a dotted notation ("Foo.Bar"), but not all. Is there any
>advantage on the JS side to having multiple modules share a top-level module
>name (memory usage, runtime speed)? Are the strings significant at all? As
>far as I can tell, the keys in the jsModules are arbitrary and just need to
>match the jsClass declarations in the LiveElements and the "// import"
>declarations in JS source files. Am I right in believing that there's no
>requirement that they match the class instances actually used in the JS
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. For sanity's
sake, I would define classes in a module as attributes of that module, rather
than using arbitrary other names, but there's little or nothing Athena can
actually do to prevent this, and as long as you aren't clobbering any names
which Athena itself uses (and almost all such names are beneath the Divmod or
Nevow namespace), it probably won't do anything to interfer with Athena.
>Anyway, that's my two questions and an aside; thanks for your patience, and
>thanks for any help you can afford.
Hope this helps,
More information about the Twisted-web