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
[EMAIL PROTECTED]
_______________________________________________
Webware-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-devel
