The web framework that scales with you. TurboGears 2.4.3 released https://github.com/TurboGears/tg2/releases/tag/tg2.4.3
@kucerarichard, what do you expect a framework to help you with?
@kucerarichard for most use cases you don't even need to involve Formencode, in many cases builtin
Convert is enough: https://turbogears.readthedocs.io/en/latest/reference/classes.html#tg.validation.Convert
Anyone that can point me in the right direction for dynamically loading controllers onto RootController? I'm a bit noob and trying to figure out how to essentially setattr(RootController, '$controllername', controller)
I'm at the point where I'm looking into hooks and milestones to start the process, but app_cfg is too early in the process, while root seems to be too late.
I'm at the point where I'm looking into hooks and milestones to start the process, but app_cfg is too early in the process, while root seems to be too late.
@privlj
See https://turbogears.readthedocs.io/en/latest/turbogears/objectdispatch.html#the-lookup-method
_lookup is probably what you are looking for.See https://turbogears.readthedocs.io/en/latest/turbogears/objectdispatch.html#the-lookup-method
the resulting html output adds a DOCTYPE as part of the include for webcam.xhtml
which it shouldn't
webcam.xhtml just is a tiny segment of html
how can I tell kajiki to not prepend <!DOCTYPE kajiki SYSTEM "kajiki.dtd"> to the contents of webcam.xhtml ?
it includes sample template code and output, which seems broken
include works fine in kajiki plain, so I suspect it's something about the loader configuration by TG that's causing that
Hey everybody! Any idea how I could use a temporary PostgreSQL db for tests, like with the pytest-postgresql fixture which creates a temporary DB process just for tests? I'm struggling finding a way to insert this one's URL into TG's configuration for the tests, because the port number isn't known up-front.
Hmm. What do you think about creating a temporary INI file inheriting from test.ini (just like test.ini inherits development.ini) but overriding the sqlalchemy.url bit? I can't think of why it shouldn't work and it seems the least intrusive way to achieve it -- it's a real config file, so everything else should "just work" when pointed at it.
the examples on toscawidgets https://tw2core.readthedocs.io/en/latest/forms/#dynamic-forms
the name of the field itself is static
The
key in practice defines "in which parameter you find the value for that widget"
so I'm not sure if maybe you are thinkingo f that one
@amol- basically I want to define the field name dynamically based on the value of tg.config['csrf.token_name']
Using the prepare method of twf.Form I am able to set the value of the HiddenField to csrf_token value available in tg.request, provided a field with name tg.config['csrf.token_name'] exists in the form
Using the prepare method of twf.Form I am able to set the value of the HiddenField to csrf_token value available in tg.request, provided a field with name tg.config['csrf.token_name'] exists in the form
I've done that recently (well a year ago so it's not super fresh). Mostly it's not too bad. There are some tools that can automate a lot of it like converting print to print(). Then run unit tests and see what breaks. Or curse the devs that didn't write unit tests and start running it and see what breaks. Really just follow guidelines for upgrading any project from 2.7 to 3.x
@tyoc213 usually porting TG projects should be fairly easy, TG itself takes care of most of the idiosyncrasies of Py2VSPy3 and to you everything is still exposed as it was. You might have to change some iterations etc, but mostly porting the existing codebase should be fairly quick.
@amol- The main problem I have now are the dependencies, for example, Mysql-some doesnt exist for python 3... I just created a tg with python 3 and they use sql alchemy... and it seem that I doesnt need mysql headers anymore (like with the version 2.7)
so I think, I will start copying things from the old tg python 2.7 project to this one, piece by piece. Or maybe I should just overwrite old requeriments with new one?? :s
@HoneySongJ I think ServerSentEvents are probably the easiest solution to that problem.
See https://www.slideshare.net/__amol__/reactive-realtime-web-applications-with-turbogears2 it's a fairly old presentation but covers both SSE and SocketIO (I'm not sure gevent-socketio still works with newest gevent versions btw).
See https://www.slideshare.net/__amol__/reactive-realtime-web-applications-with-turbogears2 it's a fairly old presentation but covers both SSE and SocketIO (I'm not sure gevent-socketio still works with newest gevent versions btw).
Hi everyone! I am working with a team of other graduate students to update an existing python 2.7 TG 2.1.5 application to python 3.7 and the newest TG release. The codebase relies heavily on utilities from the Pylons Project (Pylons, PasteDeploy, WebError, WebOb, WebTest, and Waitress), some of which have been deprecated in python 3. Our application also utilizes Zope and Paste. The codebase was started in 2004, with incremental updates throughout the years, but in need of a larger overhaul now. Is it possible, and recommended, to use TG for all of the web framework functionalities? If so, are there any resources you would recommend to help in this process?
@michael-goebel From 2.1.5 it should be doable to upgrade up to 2.4
There are some big changes, but nothing that should require you to rewrite things from scratch apart maybe the usage of TW2 instead of TW1.
My suggestion is to read the upgrade guidelines version by version -> https://turbogears.readthedocs.io/en/development/reference/upgrading.html
You can try to excecute them all at once, which is more complex but faster or just upgrade one version at the time. From 2.1 to 2.2 and then to 2.3 and so on... Once you are on TG2.2 and TW2 the jump to newer versions should be more straightforward.
For example Kallithea recently moved from using Pylons to TG2.4 when they upgraded to PY3
It was a fairly interesting project but in the end very little of the controllers had to be changed, most of the work happened in setup code.
And if they have been able to move from Pylons (which in the end is even a different framework) to TG2.4 without major hiccups, I'd say moving from TG2.1 to TG2.4 should be totally doable :D
It was a fairly interesting project but in the end very little of the controllers had to be changed, most of the work happened in setup code.
And if they have been able to move from Pylons (which in the end is even a different framework) to TG2.4 without major hiccups, I'd say moving from TG2.1 to TG2.4 should be totally doable :D
Hello everyone, I'm looking for feedbacks on a possible switch to pytest of newly quickstarted projects: TurboGears/tg2devtools#20
@CastixGitHub note that PR includes some changes to quickstart that were already discussed in a previous PR: https://github.com/TurboGears/tg2devtools/pull/19/files
The setting up your version control system is definitely out of the scope of gearbox quickstart. It might go in a dedicated gearbox command like gearbox gitignore or things like that providing a good ignore file for TG projects. But doing git init is definitely out of the scope of both gearbox and tg.
Hi everyone, I am porting the persistence code of a python application from mongoengine to ming but I couldn't figure out how to map a nested class using the imperative mode ( https://ming.readthedocs.io/en/latest/baselevel.html#ming-baselevel ). I was willing to map a class that had a nested collection of a different class.