[Webware-devel] Re: class-based config syntax

[Geoffrey T. <gta...@na...>]

At 02:39 PM 12/10/01 -0800, Tavis Rudd wrote:
>On Monday 10 December 2001 13:11, Geoffrey Talvola wrote:
> > At 01:59 PM 12/10/01 -0800, Tavis Rudd wrote:
> > >Geoff,
> > >going back to your class-based config syntax...
> > >
> > >The reason we'd need to subclass SettingsContainer is that it is
> > >possible to have settings that are in fact classes and don't begin
> > >with an underscore:
> > >
> > >##
> > >from SettingsManager import SettingsContainer as SC
> > >class Applications(SC):
> > >     class MyApp(SC):
> > >         class Dirs:  # virtual dirs like <location> in Apache
> > >             Services = '/home/tavis/MyApp/Services'
> > >             Products = '/home/tavis/MyApp/Products'
> > >         from Foo import Bar as ApplicationClass
> > >         from Foo import Whiz as RequestClass
> > >         from Foo import Bang as SessionStoreClass
> > >##
>
> > It seems very odd to me to have a value in a config file be an
> > actual class object.  I was expecting settings to be things like
> > ints, strings, lists, dictionaries, tuples, etc. but all basically
> > constants that didn't depend on code.
>
>That is part of a fundamental shift I'm proposing. If you use Python
>for configs, why not fully exploit its capabilities? If the settings
>are all constants strings then you are only using Python for its
>pretty syntax.  I'm interested in both the syntax and the dynamic
>features of Python.  Specifically, I want to be able to load either
>constants, classes, or live pre-initialized objects into WebKit.
>
>Consider this example:
>
>##
>from WebKit.Application import Application
>class MyAppClass(Application):
>     # define some custom stuff that allows collaboration
>     # between two otherwise separate applications, such
>     # as doing some complex request chaining
>
>_myApp = MyAppClass('MyApp')
>_partnerApp = MyAppClass('PartnerApp')
>_myApp.setPartner(_partnerApp)
>
>
>AppServer:
>     Applications:
>         MyApp = _myApp
>         PartnerApp = _partnerApp
>##
>
>I don't think this sort of magic will be common, but it should be
>possible.

Why not just put the "magic" part into a separate source file?  I don't see 
how putting this kind of stuff directly into the config file gains any real 
power.


> > I would propose that to specify a class as a config setting, you
> > would specify a string like "Package.Module:Class" where you can
> > leave off the ":Class" part if the class name is the same as the
> > module name.  PSP uses this convention for importing stuff and
> > specifying base classes.  So your example would be:
> >
> > class Applications:
> >      class MyApp:
> >          class Dirs:  # virtual dirs like <location> in Apache
> >              Services = '/home/tavis/MyApp/Services'
> >              Products = '/home/tavis/MyApp/Products'
> >          ApplicationClass = 'Foo:Bar'
> >          RequestClass = 'Foo:Whiz'
> >          SessionStoreClass = 'Foo:Bang'
>
>
> > The advantage is that you can import the config file without having
> > to actually import the class.  Perhaps you're just running a config
> > file pretty-printing utility, and you don't want it to have to
> > actually do the import.
>
>What's the disadvantage in doing the imports?  Performance isn't an
>issue here.  If you want to pretty-print the config module, why not
>just
>"print open(configFile).read()" as it already has a pretty syntax?

In your own example above, importing the config file actually _creates_ two 
instance of application classes.  This could have side effects that you 
don't expect to get just by loading a config file.  It might cause lines to 
be written to logfiles.  It might raise exceptions, preventing you from 
reading the rest of the config file.


--

- Geoff Talvola
   gtalvola@NameConnector.com