[Twisted-Python] Issues with roots.Collections in regards to Coil
(If this doesn't make sense, you can probably ignore it. At some point we might make a twisted-dev list.) Issues: 1) The problem where you click on a virtual host's sub-Resource in web coil and you can't configure it. Dunno why. (I fixed some similar effect bugs which were caused by *someone* using MOVED_PERMANENTLY and ignoring the fact this gets cached by browsers, but that's not the issue here.) 2) The UI assumes entities in a collection are mutable, i.e. first created, and then separately configured via a Configurator. This conflicts with stuff like making a Collection for configuring a mapping of strings (e.g. the mime types mapping in static.File). Possible solution is a custom Collection class for these situations that gets its own web coil UI. 3) Collections of Configurators or of configurables? I would think that they should stay the way they are -- collections of configurables. It's easy to wrap an object coming from a collection - that's what is done now. And it's easier to code the Collection this way, esp. since the configurable classes can be collections too, in cases where it makes sense (e.g. web.resource.Resource.) In most situations of course the Collections would only be coded in the coil plugin, but it's useful to be able to have the configurable class be a Collection. What were your issues, glyph?
On Wed, 2002-03-13 at 21:47, Itamar Shtull-Trauring wrote:
(If this doesn't make sense, you can probably ignore it. At some point we might make a twisted-dev list.)
Issues:
1) The problem where you click on a virtual host's sub-Resource in web coil and you can't configure it. Dunno why. (I fixed some similar effect bugs which were caused by *someone* using MOVED_PERMANENTLY and ignoring the fact this gets cached by browsers, but that's not the issue here.)
Whoops. Thank you for showing me The Way :-). I'll poke around the configuration at some point, but I don't really have time for it now.
2) The UI assumes entities in a collection are mutable, i.e. first created, and then separately configured via a Configurator. This conflicts with stuff like making a Collection for configuring a mapping of strings (e.g. the mime types mapping in static.File). Possible solution is a custom Collection class for these situations that gets its own web coil UI.
Yes. This really needs to have its own web UI. Are you going to be doing it?
3) Collections of Configurators or of configurables? I would think that they should stay the way they are -- collections of configurables. It's easy to wrap an object coming from a collection - that's what is done now. And it's easier to code the Collection this way, esp. since the configurable classes can be collections too, in cases where it makes sense (e.g. web.resource.Resource.)
In most situations of course the Collections would only be coded in the coil plugin, but it's useful to be able to have the configurable class be a Collection.
I had to re-read this point a few times, but I agree :-). The way that it works now is nice, because you have a good degree of flexibility in where you put the code that builds the virtual configuration hierarchy.
What were your issues, glyph?
Right now I only have one minor one -- why is the factory function an argument to registerConfigurator, but the configurableClass and configName are both attributes of the Configurator? It seems like they should all be one or the other.
Right now I only have one minor one -- why is the factory function an argument to registerConfigurator, but the configurableClass and configName are both attributes of the Configurator? It seems like they should all be one or the other.
Mmmm, well, I think there was some reason I made configurableClass an attribute - probably so Configurator can check that it is getting the right types of instances. But that's not important. And you can look at a Configurator and see what it configures. But if it bothers you a lot feel free to refactor the API and fix up twisted.coil.plugins. The factory is optional, and would have to be a class method, and python doesn't do class methods in a nice way before python 2.2. It could be an instance method, but that's just icky, it's a factory after all. So the factory has to be a separare argument to registerConfigurator.
participants (2)
-
Glyph Lefkowitz -
Itamar Shtull-Trauring