We kind of already have this, but perhaps not as clearly defined or
with a 'master switch' for it. You can change logging levels via the -
D switch. We have 'compile app'. The autoreload is just a model
setting away:
if DEBUG: reload('funky.module')
Cache stuff is a tad more tricky, especially with the slightly
unexpected timing logic web2py has, but I guess, there too you could
use a model setting
cachetime = lambda x: if DEBUG: return 0 else: return x
cache.ram('key', lambda: stuff, cachetime(60))
On Mar 11, 8:10 pm, blackthorne <francisco....@gmail.com> wrote:
> hi
>
> As my experience with web2py grows I find an increased need to make it
> work in 2 main environments/behaviors.
>
> The first mode would be "development" and it should run with smaller
> buffers, extra debug features/output, auto-refresh for files like
> routes.py so that you can edit routes on-the-fly, no caching
> mechanisms that can trick the programmers and it could even be a
> testing mode for new web2py features.
> Then there would be "production" mode, meant to be simple, stable and
> as fast as possible.
>
> Thinking about it, doesn't make sense that such different usages run
> the same way.
>
> This idea doesn't break the convention over configuration philosophy
> used in web2py.
>
> Thanks
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py Web Framework" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
