The web framework that scales with you. TurboGears 2.4.3 released https://github.com/TurboGears/tg2/releases/tag/tg2.4.3
amol- on development
disable logging and cleanup (compare)
amol- on development
Use development version of TG (compare)
amol- on development
Fix on Python 3.10 and 3.11 (compare)
amol- on development
Stop CI on first failure (compare)
amol- on development
Adapt to pytest (compare)
amol- on development
Fix generated app_cfg (compare)
amol- on development
Upgrading guides from 2.4 to 2.5 (compare)
amol- on development
Address some auth_backend lefto… (compare)
amol- on development
Switch test suite from nose to … (compare)
amol- on development
Further tweaks to make tests pa… (compare)
amol- on development
Temporarily need tempita unrele… (compare)
amol- on development
Tweak install process (compare)
amol- on development
Fix assertions and pip installs (compare)
amol- on development
Use development version of temp… (compare)
amol- on development
Initial attempt at modernizing … (compare)
amol- on development
Remove deprecated DecoratedCont… (compare)
amol- on development
Mandate context argument in Dec… (compare)
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
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!
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
import testapp.model as model
from testapp.tests import TestController
from nose.tools import eq_, ok_
class TestBreakage(TestController):
''' What the actual... '''
def setUp(self):
super().setUp()
u = model.User(user_name="what",email_address="what@where.whatever")
model.DBSession.add(u)
u = model.DBSession.query(model.User).first()
# Crash, because querying causes a transaction commit. But...
# which transaction? Why does this seem to cause the second
# test (only) to fail?.
def test_broken_1(self):
ok_(True)
def test_broken_2(self):
ok_(True)