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