[TransWarp] Domain model objects as utilities?

John Landahl john at landahl.org
Fri Oct 17 21:02:57 EDT 2003

On Fri, 17 Oct 2003 19:18:03 -0400, Phillip J. Eby <pje at telecommunity.com> 

> If you're loading an .ini file into your app component, you can still 
> use [Provide Utilities], and all your utilities will be loaded using the 
> app component as their parent, so they'll be able to relate to one 
> another properly.

Ah ha!  That sounds just just the right thing.  I'm not sure I'd know how 
to accomplish it, though.  Or are you saying that this is already 
happening?  It doesn't seem that my classes from [Provide Utilities] know 
about app-object components, though.

> DM's don't have anything to do with databases, per se.  You can make 
> DM's that make up random data and poke it in the objects if you want.  
> ;)  In any case, it's certainly possible and often useful to make DMs 
> that wrap some kind of client-server communication, load from file, or 
> whatever.  So, don't feel limited to just using them for database access.

Sure, I've considered this off and on, especially doing some sort of 
client-server DM.  I may at least write a DM to pull the data from Cheetah 
templates into Host objects (and their various component objects), but one 
potential snag would be the need to periodically pull in new data to 
existing objects from potentially disparate DM sources (and potentially 
partial data at that, such as a few Partition definitions here, a few 
Package definitions there).  Currently I've been using a method on the 
Host class which can update the object with new and partial data (this is 
not currently using adaptation, but I've been considering adding adapt() 
to the picture).

> Note that the current system doesn't let you "go through the possible 
> entries", unless of course you're supplying the possible entries.  
> There's no way to iterate over 'foo.tools.*'.

Right, I noticed this limitation a while back with Python's ConfigParser, 
so I'd be running through a hardcoded list.

> You can, however, create semantic extensions to be used in an .ini 
> file.  [Provide Utilities] is an example of such a semantic extension, 
> and peak.web's 'resource_defaults.ini' showcases another interesting 
> one.  Take a look at the first part of 'peak.ini' under 
> [peak.config.iniFile.sectionParsers] to see how it's done for [Provide 
> Utilities] and others.

This sounds very interesting, and I've been wanting to learn more about 
how these sections and components work, so maybe now is the time.

More information about the PEAK mailing list