[Twisted-Python] Configuration: The Never Ending Story.
Moshe Zadka
moshez at zadka.site.co.il
Fri May 11 12:49:17 EDT 2001
On Fri, 11 May 2001 19:36:24 +0300, Chris Armstrong <carmstro at dynup.net> wrote:
<snipped agreement on the axioms>
> > .getAnswer(name, answer) --> notify the application that an answer has been
> > given to a particular question
> > It can throw an InvalidAnswer exception with
> > a string for a reason. This is for
> > application-level verification, and is discouraged.
>
> name change: setParamaters()
setParameter() sans the 's'. One call per parameter
> > .endAnswer() --> the "application" promises that no methods of the object
> > will be called between a series of .getAnswer()s and
> > .endAnswer(). So, this means that if the UI got a bunch
> > of answers, it will call .getAnswer() several times, and
> > then .endAnswer(). The UI will *check* for this method's
> > existance, and will not call it if it doesn't exist.
>
> name change: i'm not sure what, but endAnswer doesn't sound right.
> What this is for is deferred calculation of answers. the not-calling-methods
> thing needs to be thought about, so we don't have some weird bugs where TPy
> goes completely haywire while configuring. (For instance, what if we're
> configuring a web server through the web interface?)
That's the classical example for why it's needed. Since the UI should
do something like that
for parameter in stuff_i_got:
object.setParameter(...)
object.endParameters()
Then everything is fine.
That's a classical case of "if there's a doubt, there isn't a doubt": if the
UI is *not* sure it won't call other methods, it *should* call .endParameters()
It is *not* promised that there won't be multiple batches -- that's a QoI
issue.
> name change: [from .hasAnswer to] hasValue()?
Yep, definitely
> > Objects which can be created by the UI should have an __init__ which
> > can be called without arguments. If there is any initialization which
> > requires arguments, it should be done in endAnswer(). The UI also promises
> > not to call .endAnswer() for an object if there any questions which have
> > not been answered and do not have a default (.hasAnswer is false.)
>
> Ok, instead of __init__s that don't take arguments, we have klass.getInitArgs()
> that is another set of questions that the user answers before the UI
> instantiates the object (well, it'll have to be klass.__dict__['getInitArgs'](),
> as glyph pointed out to me).
No, we won't.
We'll have copy.copy(klass.initParameters). No need to make it a callable,
really.
> Also, when we instantiate the object, we call
> newObject.setParent(parent), as moshe talks about in the open questions at
> the bottom of his mail.
> name change for all of the following: *Parameter
Yes.
> >
> > class BooleanQuestion:
> > class IntQuestion: (can have .min and .max)
> > class FloatQuestion:
> > class StringQuestion: (can have .maxlength)
> > class LongStringQuestion: (same as above -- it's a hint to the ui)
> > class InterfaceQuestion: (specify interface, valid answers are objects)
> > class ArrayQuestion: (an array of the same kind of question)
>
> moshe told me this was a thinko, so forget about array of questions :)
I misunderstood radix. Let me clarify:
It's something like if you want to have a set of Servers in a selector:
ArrayParameter(InterfaceParameter(ServerInterface))
> > class DictQuestion: (a dictionary mapping strings -> same kind of question)
>
> I don't really get this one.
Think of a web Resource which is a folder.
Then you can have
{'children': DictParameter(InterfaceParameter(WebResourceInterface)) }
[re __implements__]
> I seem to remember some standardization of this that was proposed in a PEP.
> Maybe we should use that standard for now, but of course just use our own
> implementation of the implementation-checking stuff. (tongue twister, eh?)
Python will not have *any* implementation of interface checking stuff.
Of course, we'll just take objects up on their __implements__ word,
not check through methods.
> > * How do we allow the object to signify groupings of questions?
> > Suggestion: this means the design is bad -- break down the object
> > into smaller objects
>
> I'm not sure of my stance on this. I'll try to think of some examples and
> discuss.
I myself have misgivings on that. But maybe we can punt on it for now?
--
"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