![](https://secure.gravatar.com/avatar/7ed9784cbb1ba1ef75454034b3a8e6a1.jpg?s=120&d=mm&r=g)
On Thu, 17 May 2007 17:57:35 +0300, kgi <iacovou@gmail.com> wrote:
Hi all.
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.
[snip]
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, though.
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 source files?
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, Jean-Paul