Louis, I think you're getting a little pushback because you make a rather extreme criticism in the face of a fairly small issue that (a) you can easily work around right now and (b) would not be difficult to fix in the framework. Furthermore, the issue at hand affects features of web2py (i.e., admin and appadmin) that most other frameworks don't even have.
Note, aside from adding a few lines in the admin app to have its sessions stored in the db, another option might be to edit the handler file used to start web2py. In that file, you should be able to do something like this: from gluon.settings import global_settings global_settings.db_sessions = True Your handler file shouldn't change on web2py upgrade, so this setting will remain in effect. If all you really need is appadmin, then you could also directly edit the appadmin.py controller so it uses the Auth of its own app rather than the admin app (this won't change when you upgrade web2py because the appadmin.py file is part of the app code and is not automatically overwritten on upgrade). In fact, this is already how the appadmin "manage" feature works, so if that feature is adequate for you, you don't need to make any changes at all. As for error tickets, if you want them to go directly into the db instead of initially being written to the filesystem, I think you can add the following in a model: request.tickets_db = db To then view the tickets via admin, you need a "ticket_storage.txt" file in the app's /private folder that includes the URI if the database. I suppose this poses a problem on Heroku, so we may need to come up with an alternative means of getting the URI. More generally, perhaps we could add a feature that would allow a flag to be set indicating that the runtime environment lacks a persistent filesystem, in which case, sessions and error tickets would automatically go in the database. The framework obviously already includes the needed functionality, as this is what is done on GAE -- we just need to generalize the setting so it can be used on any platform. The thing is : my disappointment here lies in the architecture, not the > features. > > There is little contribution to be done when regarding an architectural > issue (except a big refactoring of course, which you can't expect a regular > contributor to do on his own). > I don't think this is an architectural issue or requires a big refactoring. We already have the functionality in place to work on GAE -- it just needs to be tweaked to apply more generally. > I think it is fair to share personal experiences regarding the framework > (good or bad), as long as they are relevant. > Of course, but consider the tone. Every improvement to web2py is contributed by a volunteer. > Same goes for appadmin.py and its permission-based "manage" feature which > is described as a role-based database access. Why would you define roles in > a local environment ? Obviously this is meant to go on production in a > secure back-office... > As noted above, the "manage" feature of appadmin does not in fact delegate authorization to the admin app. It instead relies directly on the app's own Auth system (which is how it is able to use role-based authorization). In any case, I agree that to the degree that it is feasible, it should be possible to run admin and appadmin in production. They are probably not the ideal tools in "serious" production environments, but they have their place as a convenience in some settings. We should be realistic, though -- if you don't have a persistent filesystem, the admin app will have its limitations. Anthony -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
