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
##
Without using something like SettingsContainer those custom classes
would be treated as if they were SettingsContainers themselves, which
is definitely not what we want in this case.
There is another alternative: create a slightly modified Python
syntax that uses a different keyword than 'class' for
SettingsContainers. A custom import_hook (via the standarde ihooks.py
module) would be used to import the config modules:
##
config Applications:
config MyApp:
config 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
##
Once the import hook has been loaded, "import WebkitConfig" would
find WebkitConfig.cfg, translate it to the syntax in the first
example above and then load it as if it were WebkitConfig.py. To
WebKit and the end user it would be seemless.
We could even get rid of the keyword completely:
##
Applications:
MyApp:
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
##
The advantages would be:
* it's very concise
* ALL other Python syntax would work as expected (even class)
* no need to use the 'class' keyword, which is misleading in this
situation
* the experienced gained working with the import hooks here would
transfer to Cheetah and other Webware components that need to build
servlet factories that load a customized Python syntax
The disadvantages would be:
* it would require bit of work
* we would have to be careful not to create clashes with other import
hooks, such as the ones used by ZODB.
Quixote uses the technique to load its .ptl template files. Their
custom import hook module is 152 lines long including comments, so it
doesn't look very difficult.
In dictionary format these settings would be expressed as:
##
from Foo import Bar as ApplicationClass
from Foo import Whiz as RequestClass
from Foo import Bang as SessionStoreClass
Applications ={'MyApp':{'ApplicationClass':ApplicationClass,
'RequestClass':RequestClass,
'SessionStoreClass':SessionStoreClass,
'Dirs':{'Services':'/home/tavis/MyApp/Services',
'Products':'/home/tavis/MyApp/Products',
}
}
}
##
Either format would be valid and you would be able to mix the two
where necessary:
##
from SettingsManager import SettingsContainer as SC
class Applications(SC):
class MyApp(SC):
Dirs = {'Services':...,
'Products':...,
}
from Foo import Bar as ApplicationClass
from Foo import Whiz as RequestClass
from Foo import Bang as SessionStoreClass
##
Internally Webware would store all settings as dictionaries.
Tavis
_______________________________________________
Webware-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-devel
