![](https://secure.gravatar.com/avatar/3a0692e41269653ec7ac24c7936c8dc6.jpg?s=120&d=mm&r=g)
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. First of all, it looks like the mapping of package/module to JS source file "ought" to be contained in a plugin. This is described in the Athena page, and (almost) mandated by the fact that athena.py's allJavascriptPackages() performs a plugin search like this: from nevow import plugins [...] d = {} for p in plugin.getPlugIns(inevow.IJavascriptPackage, plugins): d.update(p.mapping) return d ... which uses the fact that a module passed to getPlugins() will use that as the search path, so this will in fact search nevow/plugins/, and that's hard-coded. However, the story doesn't end there: nevow/plugins/__init__.py contains the line: __path__ = [os.path.abspath(os.path.join(x, 'nevow', 'plugins')) for x in sys.path] This means that if I look for modules under nevow/plugins, I will magically pick up any module that has been put under a nevow/plugins directory in my sys.path. (Innocent onlookers can see the bottom of http://docs.python.org/tut/node8.html for the details; I didn't know this was possible until I saw this method being mentioned in the twisted plugin docs at http://twistedmatrix.com/projects/core/documentation/howto/plugin.html). Now this is quite clever, but if I've understood the mechanism right, it's not necessarily all that handy, because it dictates either the location of particular directories within one's project (i.e. my athena code is not at the top-level of my code tree, so I'd prefer not to have 'nevow/plugins' at the top-level for getPlugins() to pick up via sys.path) or an unnecessary entry into sys.path. 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. 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). 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? Anyway, that's my two questions and an aside; thanks for your patience, and thanks for any help you can afford. Regards, Ricky