[PEAK] Re: PEAK design pointers

[Phillip J. Eby]

At 10:24 AM 3/6/04 +0000, Paul Moore wrote:
>"Phillip J. Eby" <pje at telecommunity.com> writes:
>
> >>But I can't work out how to connect them all together (well, I can,
> >>but that's when all the nice modularity and flexibility breaks
> >>down...)
> >
> > Well, if I understand you correctly, I'd probably write something that
> > would spawn an events.Task for each of the databases to be monitored,
> > and create another Task that accepted the results of each of the other
> > tasks in order to prepare the consolidated report and mail it out.
>
>Right - it sounds like events.Task is the place for me to look. That's
>excellent. As I said, it's pointers to the right places to look which
>I was lacking...

Note that normally the way you'll do tasks is to wrap an object method with 
events.taskFactory.  E.g.:

     def someMethod(self,...):
         # blah blah
         yield something; events.resume()
         # ...

     someMethod = events.taskFactory(someMethod)

Then, calling 'someMethod(...)' will return a running 'events.Task' for 
that invocation of the method.

Often, you'll have objects that want a per-instance task to do something 
for that object, in which case you'll use something like:


     def myTask(self):
         # blah blah
         yield something; events.resume()
         # ...

     myTask = binding.Make(events.taskFactory(myTask), uponAssembly=True)

which will set the 'myTask' attribute to a task object as soon as the 
component is plugged into a complete application.  Or, if you don't want 
the task to start immediately, you can leave off the 'uponAssembly' part, 
in which case the task will start the first time you reference the 'myTask' 
attribute of the instance.


>One other point, which I've never found a really good configuration
>answer for, is that I have a number of SQL queries I may want to
>execute (based on application line options, and the like). I can store
>these in separate files, and have configuration items
>
>[queries]
>performance = config.fileNearModule("monitor", "perf.sql")
>space = config.fileNearModule("monitor", "space.sql")
>
>and so on. (Or the ZConfig equivalent...)
>
>But the SQL is usually quite short, and I wonder whether putting it
>"inline" would be better. What do you think?

That really depends more on your application/frameworks's target 
audience.  There are a zillion ways to do it, and some are more convenient 
for developers at the expense of being more complex for less-technical users.

Of course, maybe you could just put the SQL in the repository too.  :)