[Twisted-Python] Configuration, Final Spec
Moshe Zadka
moshez at zadka.site.co.il
Sun May 13 01:31:32 EDT 2001
On Sat, 12 May 2001, Glyph Lefkowitz <glyph at twistedmatrix.com> wrote:
> IMHO, people *should* inherit from it, so that we can have some visibility on
> what implements it. I agree that it should provide as little functionality
> as possible, however.
No, people should put it in the __implements__ attribute.
> In my humble (but correct) opinion, it is *always* bad API design to force
> the caller to "promise" something. (Sometimes, other design concerns
> mitigate this decision, but I don't see one here. However, I have frequently
> joked about having a neon sign in my office, for design discussions, that
> says "IT IS NOT THE CALLER'S RESPONSIBILITY" in 10-foot-tall letters)
>
> I would much rather see a .getParameters() -> dict / .setParameters(dict).
> It seems more symmetrical, and if you can "promise" that (A) setParameters
> may be called some number of times and (B) endParameters() will *always* be
> called afterwards, we can put that loop into the config side of the code.
>
> Any reasons why it can't be done this way?
Yes. In the usual case, where you don't need a .endParameters(), then the
code will be *much* clearer. You also missed the place where I say
".endParameters() will not be called if it doesn't exist".
See axiom 4 -- certainly
def setParameter(self, name, value):
setattr(self, name, value)
(which is the usual case)
Is much quicker then
def setParameters(self, dict):
for name, value in dict.items():
setattr(self, name, value)
And another good reason -- this makes it much easier when doing
application-level validation, to know what failed:
# configuring RSA
def setParameter(self, name, value):
if not isPrime(value):
raise ValueError("not prime")
setattr(self, name, value)
> Another interesting open question (although not one I'm sure this code has to
> address) is how to get the respective configuration interfaces to represent
> object identity. (e.g. I want to mount the *same* web resource on /foo, on
> /bar)
This code isn't the one that should address it -- this is UI's responsibility.
Take *another* look at the way Zope does it.
> However, I prefer the register(klass) way, both for clarity and efficiency.
> Explicit is better than implicit.
Indeed, I've decided I agree, for a different reason -- we do not want
spurious options for the user.
> Your code has a bug in it, which is a good example of why I like to actually
> inherit from interfaces :). You don't define "endParameters".
No it doesn't. It's permissible not to have .endParameters(), .setParent()
and .initParameters. The first two will not be called if they don't exist.
> One more question -- why doesn't the Configurable interface class actually do
> some things, like data validation? It sounds like it'd be possible
> (isCorrectInput method on the Parameter classes, or somesuch...)
I've thought about it, and decided against it -- since the UI needs to know
so much about the validation anyway, I prefer to putting the knowledge in
the UI. Sure, when we realized what is convinient for two UIs, we can have
some nice functions to help UIs -- but *outside* the Parameter class.
The classical example is that the UI might need to write the validation
code in JavaScript, for DHTML forms. Surely, a method written in Python
won't help...
> On the whole this looks like a good proposal, although I'm still not entirely
> sure what the final end-user experience of configuration will look like.
Well, I've already gave an example of what it would look like with the
command line. Mutatis-mutandis, we can pretty much imagine how to translate
it into web-based. Of course, many options still remain, but I don't think
I care about UIs: I've specified enough information for the UI -- now
the UIs can compete. (We can have 10 different web-based UIs, and choose
among them)
--
"I'll be ex-DPL soon anyway so I'm |LUKE: Is Perl better than Python?
looking for someplace else to grab power."|YODA: No...no... no. Quicker,
-- Wichert Akkerman (on debian-private)| easier, more seductive.
For public key, finger moshez at debian.org |http://www.{python,debian,gnu}.org
More information about the Twisted-Python
mailing list