Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Nov 29 23:26

    amol- on development

    Do not rely on deprecated getar… (compare)

  • Nov 29 23:25

    amol- on development

    Do not rely on deprecated getar… (compare)

  • Nov 29 21:02

    amol- on development

    Remove coverage as a mandatory … (compare)

  • Nov 29 21:01

    amol- on development

    Update run-tests.yml (compare)

  • Nov 29 20:40

    amol- on development

    simplify test dependencies inst… (compare)

  • Nov 29 20:38

    amol- on development

    Avoid installing unstable relea… (compare)

  • Nov 29 20:16

    amol- on development

    Update run-tests.yml (compare)

  • Nov 23 21:51

    amol- on master

    Switch to https transport (compare)

  • Nov 23 21:37

    amol- on master

    Remove 3.6 (compare)

  • Nov 23 21:34

    amol- on master

    Moving to github actions, proof… (compare)

  • Nov 23 20:48

    amol- on 0.2.2

    (compare)

  • Nov 23 20:48

    amol- on master

    Version 0.2.2 (compare)

  • Nov 23 01:14

    amol- on development

    Update devcontainer.json (compare)

  • Nov 23 01:10

    amol- on development

    Experimental github codespace (compare)

  • Nov 15 19:02

    brondsem on 0.12.2

    (compare)

  • Nov 15 19:02

    brondsem on master

    version 0.12.2 (compare)

  • Nov 15 18:29

    brondsem on master

    MIM: add support for UUID types… (compare)

  • Nov 15 18:29
    brondsem closed #52
  • Nov 14 21:36
    brondsem opened #52
  • Nov 14 21:34

    brondsem on uuid

    MIM: add support for UUID types… (compare)

Alessandro Molina
@amol-
@jknapka Isn't that what you already achieve if you have @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
Joe Knapka
@jknapka
I wasn't aware of this annotation, I guess because I don't use Tosca forms. When I updated my app from TG1 to TG2, converting my Tosca forms to TW2 was frustrating so I switched to WTForms. WTForms has (IMO) much clearer documentation than TW2.
Alessandro Molina
@amol-

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.

I suggest you have a look at https://turbogears.readthedocs.io/en/latest/turbogears/validation.html?highlight=validation#the-error-handler so that you can pass the errors back to the error handler and display the form with the errors.
Nils Philippsen
@nphilipp
@amol- Do you mean that you rewrite the docs, or TW?
Alessandro Molina
@amol-
the docs
:D
Nils Philippsen
@nphilipp
phew
Alessandro Molina
@amol-
TW itself does its job if you know how to use it, it's just that you have to read the source code every time you don't use for more than a week :P
Nils Philippsen
@nphilipp
BTW, how alive are the TW2 related projects -- tw2.jquery, tw2.dynforms and the like? I've submitted PRs there long ago (ex. to update to a current jquery version) but haven't gotten responses.
Alessandro Molina
@amol-
tw2.jquery, tw2.dynforms etc are pretty dead. I don't think anyone is using them nowadays. At least personally I usually do things with different JS libraries
Nils Philippsen
@nphilipp

I don't think anyone is using them nowadays.

Hmm. I do. shrug

Alessandro Molina
@amol-
I think that the original authors are not using them anymore
so if you want to step up and claim maintainership it's a good time to do so
Nils Philippsen
@nphilipp
I think at least one of them was done by Ralph Bean, right? He's a colleague of me so that should be easy enough.
Out of curiosity, what alternative JS libs do you use?
Alessandro Molina
@amol-
I personally still contribute to tw2.core and tw2.forms because they still have a value in modern apps, but tw2.jquery given the standard nowadays is to use webpack or similar and for dynforms I usually go with Vue or React
but we recently used the Growing table for a project and we had to copy the widget into the project to make a fix to the template
but I think it happens once a year or so that we use something from dynforms
Nils Philippsen
@nphilipp
Yeah, I only use dynforms for a set of emails, phone numbers in a "personal data" form in an app of mine. But it does its job, more or less (albeit the UI looks a little dated).
Alessandro Molina
@amol-
Ok, new TW2 documentation is at a fairly decent point. As soon as I can get access to readthedocs.io from Ralph I'll make it available to everyone
Alessandro Molina
@amol-
nvm, got a reply from him :D
Alessandro Molina
@amol-
https://tw2core.readthedocs.io/en/develop/ <- here is the new documentation
Aditya Padwal
@adityap31
Guys, just wanted to know. How big will be TurboGears in next 2 years ?
Alessandro Molina
@amol-
are you asking in terms of LOC or in terms of which part of the world will be ruled by TurboGears if it gains self conscience and declares war against humanity?
Aditya Padwal
@adityap31
Oh! Wrong gitter lobby, I guess 😊
Hey @amol- I am a Django Developer and was thinking of creating something with TG.
Alessandro Molina
@amol-
That would be great, I'm always eager to hear feedbacks about the framework and what can be improved
Joe Knapka
@jknapka
Hey guys! I have run into a problem with TG24 and nosetests that I don't understand and have been wrestling with for several hours. Specifically, this test case run in a newly-quickstarted TG24 app, which raises a "This transaction is closed" exception from SQLAlchemy:
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)
Alessandro Molina
@amol-
@jknapka Is that all you need to reproduce it?
Alessandro Molina
@amol-
That usually means you already commited / rolled back the transaction and you are trying to do more work there
Which version of 2.4 are you using? 2.4.0a1 or 2.4.0a2? If it's a1 I suggest you try to update because there were changes to the transaction manager due to some compatibility issues with transaction library
Alessandro Molina
@amol-
Ok, I see what's going on
it's in setUp, so it means it's outside of any request. The transaction manager is not involved.
but super().setUp() does call setup-app which does commit the transaction that is using to initialize the database (see websetup/schema.py and websetup/bootstrap.py both of those commit a transaction)
as the transaction is global, you are reusing their transaction, but they arelady committed it
You need to change that code to be:
        try:
            u = model.User(user_name="what",email_address="what@where.whatever")
            model.DBSession.add(u)
        except:
            transaction.abort()
        else:
            transaction.commit()
every time you do something with DB outside of a turbogears request you need to manage the transaction on your own
As tests fixtures are not within a controller action called within a request, they are one of those cases where you need to manage on your own the transaction life.
@jknapka hope I addressed your doubts
Joe Knapka
@jknapka
@amol- Thank you... sorry I didn't reply sooner, it's 9AM here :-) I suspected it was something along these lines but I don't know sqlalchemy or the transaction module well enough to get to the bottom of it.
Yes, that totally works! Thank you!
Alessandro Molina
@amol-
:+1:
Joe Knapka
@jknapka
Hmm, still confused actually. If I create any DB entities inside my test methods, the same error occurs (unless I manually commit or abort the transaction). But test methods should be run inside a TG request and therefore with automatic transaction management, correct?
Alessandro Molina
@amol-
no
the test method is still outside of a TG reuqest
you would be running within a request if you did self.app.get(....) then that triggers request
otherwise in a test method you are not within an HTTP request
it's just a plain normal python function
so you need to commit the things youself