The web framework that scales with you. TurboGears 2.4.3 released https://github.com/TurboGears/tg2/releases/tag/tg2.4.3
@HashimMalnus_twitter Late answer, but the framework provides an authentication and authorization layer out of the box: https://turbogears.readthedocs.io/en/latest/turbogears/authentication.html
There are plugins for registration or for authentication through Google, Facebook etc...
TurboGears 2.4.0a1 pre release was pushed to PyPi to allow everyone to try it.
It's a major version with the final result of the multi year effort of rewriting the TurboGears configuration system in a more robust, predictable and easy to use way while retaining backward compatibility.
If anyone is interested here is a short article on the new configuration system: https://medium.com/@__amol__/welcome-turbogears-2-4-6f5f9f0a47a0
tgext.crud 0.9.0 was released with support for sorting over related entities in the CRUD Table and a few bugfixes.
See https://github.com/TurboGears/tgext.crud/releases/tag/0.9.0 for the release announcement
tgext.pluggable 0.8.0 has been released.
This version adds support for pluggable applications in TurboGears 2.4, most pluggable applications have been tested and ported to 2.4, if you need to update check their github repository for latest changes.
@samjustice
There is a guide on how to run TG on Google App Engine: https://turbogears.readthedocs.io/en/latest/cookbook/deploy/appengine/
And I know a few people using PythonAnyWhere: https://www.pythonanywhere.com/
Heroku also works pretty well: https://www.heroku.com/
I used it for a bunch of minor projects
For the documentation a patch is appreciated, it's currently a non-concern as it's built on readthedocs using Py2, so Py3 support wasn't a need so far.
TG has always supported many different libraries and backends, and it's hard to deprecate them because there are people using them out there, but without third parties help it's hard to maintain them all because it's hard to notice breakages (I never used CherryPy for TG for example, always Waitress).
So any help on that is greatly appreciated!
Still thinking of a proper place where to add longer posts btw, as Google+ was convenient because it allowed long posts. For releases changelog the "Release" tab in GitHub might be the proper place
Hey Alessandro, I'm trying to do a thing that I'm not sure how to do. I am processing form results in (say) MyController.form_handler(). If the form doesn't validate, I want to pass the form object back to the original exposed MyController.form_start(self,form=None) method. That method uses @expose('form_template_name') to return a page that renders the form.
So I try doing
return self.form_start(form=erroneous_form)
but this does not work because the form_handler() method lacks the @expose('form_template_name') annotation -- since form_handler() is merely a POST handler it normally ends with a redirect rather than returning a result, and therefore uses the @expose() annotation.
Obviously I could add @expose('form_template_name') to the form_handler() method, but that seems wrong/inelegant. Is there a way to return the result of an exposed method and tell that method what template to use to render its results? Eg something like:
return self.form_start(form=erroneous_form,template_name='form_template_name')?
@validate(YouForm, error_handler=form_start) as a decorator for form_handler? That's how validation for forms is expected to work: https://turbogears.readthedocs.io/en/latest/turbogears/widgets_forms.html#validating-fields
TW2 had nearly zero documentation. But I started rewriting it a few weeks ago. So there is now a newdoc branch ( https://github.com/toscawidgets/tw2.core/tree/newdoc/docs/source ) where I'm doing all the work of rewriting it.
But if you are using WTForms I guess you have to adhere to WTForms way of doing things. You should still be able to use the error_handler to switch action of the controller in case of errors, but you will have to roll your own validator as WTForms forms aren't supported as validators by tg out of the box.
dynforms