First it must be decided if the configuration should be on the server or on
the application level. A configuration per application would be more
flexible so I'd prefer that. Basically all that's needed is a configuration
file which could be similar like the language translation file. The
settings should only be read once when web2py is started. It would be
convenient to edit the configuration in the admin interface (on an own page
like the database administration). In the admin interface the settings
could automatically be refreshed when they are changed so you would not
have to restart web2py in this case just to reload the configuration.
In the application itself all you need is a method to read those settings
from the configuration. Maybe this could be added to the cache object but
I'm not really sure if this would fit in there. e.g.
connection = cache.get_configuration_property('dbconnection')
if not added to the cache a global application object would probably be
necessary.
Am Donnerstag, 5. April 2012 00:48:24 UTC+2 schrieb Anthony:
>
> Do you have a proposal for how web2py should do this?
>
> On Wednesday, April 4, 2012 6:23:11 PM UTC-4, Alex wrote:
>>
>> each app is running in an own instance with an own webserver and of
>> course an own URL. But I cannot distinguish by the URL because this does
>> not work for cron jobs.
>>
>> I think the solution with reading a properties file and caching is fine
>> for me. Still, I think this feature is necessary for almost every real
>> world application and thus it would be good to have it in web2py. For
>> example in java application servers you can configure db connections in the
>> admin console and access them via jndi. In grails there is an own
>> environment configuration so e.g. you can set different data sources, log
>> settings and so on for testing, development and production environment (and
>> of course you could use your own environment, e.g. customer specific).
>>
>> Alex
>>
>> Am Mittwoch, 4. April 2012 04:04:08 UTC+2 schrieb Anthony:
>>>
>>> thanks for the cache info. I think that's the way to go for me. I'll
>>>> create a function to read the connection properties and add the cache
>>>> decorator for the function. It is still just a workaround but at least it
>>>> should not have any performance penalties.
>>>>
>>>> I'm still wondering why such an essential feature is missing...
>>>>
>>>
>>> How do you know which customer is accessing the app -- does something in
>>> the URL distinguish customers? Whatever it is, can't you just create a
>>> dictionary mapping the relevant request parameter to the appropriate data
>>> source URI and either keep that dictionary in a model file or import it
>>> from a module?
>>>
>>> Anthony
>>>
>>
