On Jan 27, 2007, at 10:38 PM, Ian Bicking wrote:
(...)
>
>>> What I mean by "possible" is that a single TG app doesn't really
>>> need
>>> a paste.deploy config file and the CP configfile, built by the
>>> developer, we're used to is enough. A paste.deploy config is needed
>>> when a TG app distributed as an egg wants to be mounted side by side
>>> in a bigger site.
>> that sounds like too many config files, I believe we need to think
>> this better, they are all dict based files. I see 3 possible
>> solutions
>> a) handle then totally separated backed by docs, howto write a
>> paste.deploy config file, howto .... b) Do some python-foo to build
>> the config files automagically, c) have one BIG config file with all
>> the options and do less python-foo to build the separated ones.
>
> If you want to build up the config in Python or some custom way, you'd
> just want to conform to the paste.* entry points (app_factory,
> filter_factory, etc).
>
> You could also just use the Paste way of accessing things from
> everywhere. Paste doesn't allow a single application to have
> subsections, but the keys can look like whatever you want, so if you
> really want "/foo session_timeout = 60" or something, you could parse
> that into {'/': {'session_timeout': '60'}}. I dunno... generally I
> find
> this kind of control unnecessary once you've split things into formal
> apps -- overriding things by path inside an application is error
> prone.
>
> Also I think there's a config file inside TG projects, right?
> While you
> can do that, I prefer just putting that into Python code. So that
> means
> any stuff that isn't optional or shouldn't be configured on deployment
> goes into Python code. I haven't kept up with TG on this, but I
> seem to
> remember it was putting some of that stuff into config files inside
> the
> package.
Yep. TG loads configuration files from the "config" package inside TG
apps. Those config files are loaded with ConfigObj to allow python
values. We also have a home-made syntax to define loggers which live
at config/log.cfg. That configuration system shall remain in 1.1 for
backwards compatibility but can easily be merged with a deployment
config in plain ini format. One thing I'd like to stress is that
deployment configuration would be optional. "tg-admin serve" would be
able to generate one on the fly for simple TG apps wich would just
mount the "main" app_factory entrypoint from the app's egg at "/".
However, given that TG apps would have paste deploy's entry points, a
deployer could write a custom deployment config to build a stack with
TG (and non-TG "paste enabled") components.
>
>>> - We can start investigating/stealing useful tools from other
>>> projects.... (I18NToolbox, Pylons version of EvalException,
>>> HTTPEncode, etc, etc...)
>
> BTW, I've thought about splitting off the Paste exception stuff into a
> separate project, and doing some potentially backward-incompatible
> changes to support better templating and customization, leaving the
> Paste stuff stable (which is why the Pylons changes haven't made it
> back
> into Paste) and only deprecating the Paste stuff when the new
> project is
> stabilized.
Thats good to know :) I must admit I really like Pylons'
EvalException so having something similar as a stand alone package
for use in TG would be great.
>
> (HTTPEncode, OTOH, shouldn't be used outside of experiments yet
> because
> I'm still heavily refactoring it.)
Ok, I just mentioned it as an example to illustrate the fact that we
could investigate any WSGI component for use in TG, not that we need
HTTPEncode at the moment... :)
Alberto
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears Trunk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~----------~----~----~----~------~----~------~--~---
