[TransWarp] Domain model objects as utilities?

[Phillip J. Eby]

At 03:55 PM 10/17/03 -0700, John Landahl wrote:
>So for this purpose the one Host object needs to be singleton-ish.  Up to 
>now I've been creating it at the top-level application object and offering 
>it out from there.  That's worked fine, but I'd like the various 
>Component-based classes which do all the work to be pluggable, so was 
>experimenting with [Provide Utilities].  Loading the classes manually in 
>the application object from values in an .ini file would probably be fine 
>-- would importObject be the thing to use there?

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.


>>Are you sure you don't want to have a service component that's 
>>responsible for retrieving the instance?  Like for example, a DM?  The DM 
>>can also be responsible for loading the object's state, since that's what 
>>DM's are for.  :)
>
>Client programs are not allowed direct database access, so I only use DMs 
>on the server side.  On the client side the Host object is initially 
>populated from a Cheetah template (which allows users a high-level, 
>template-driven way to specify configurations), but updates to the model 
>are received periodically from the server and loaded into the appropriate 
>place.  This allows client-side data to initially be practically null if 
>desired, with all information coming from a central source, or exactly the 
>opposite depending on local policy.

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.


>something more like:
>
>   [foo.tools]
>   package = importObject("foo.tools.RPMPackageTool")
>
>   [foo.tools.RPMPackageTool]
>   install = "rpm -i %(package)s"
>   remove  = "rpm -e %(package)s"
>
>And then the application object would go through the possible "foo.tools" 
>entries and Obtain each of the objects, re-offering them with the 
>appropriate interface (e.g. IPackageManagerTool).  Using .ini files also 
>means they'll still be available as e.g. "foo.tools.package" if that seems 
>to be appropriate somewhere.

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.*'.

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.

Note that you can define section parsers *in* an .ini file, or you can do 
it in a seperate .ini file loaded ahead of time.  These parsers will apply 
when loading files into any child component of the component where the 
section parsers were created.

Custom section parsers can only be used for section names that have a space 
in the middle of them, but that's convenient for making something like:

[My Tools]
blah = blah

Note that you can't change the *syntax* of .ini files; all lines in a 
section still have to be something = something, with indentation to allow 
multi-line entries.  All you get to change is what code is run for each 
key=value pair.