Implement form.as_table, as_ul, as_p using templates

2017-02-03 Thread Gert Steyn
Hi All Is anybody against using the new renderers (used to render widgets) to also render the form? I suggest something like: class BaseForm(object): template_prefix = '' template_name = 'django/forms/form_as_table.html' def render(self, template_name=None): template_name =

Re: Google Summer of Code 2017

2017-02-03 Thread HITESH V. BHAGCHANDANI
My college blocks ports for IRC and am unable to communicate freely with the django community. By the way, I have joined only a few days ago and would like to know where I can post my queries regarding details( which function to use, what file to edit and so on) about any patch that I'd be writ

Re: Google Summer of Code 2017

2017-02-03 Thread Tim Graham
There are web clients for IRC such as irccloud.com that you can use to avoid port restrictions. This mailing list isn't the best place for basic contributing questions. The #django-dev IRC channel or the mentorship mailing list could be suitable for new contributor questions. https://groups.goo

Re: Implement form.as_table, as_ul, as_p using templates

2017-02-03 Thread Tim Graham
There's an old accepted ticket for it: https://code.djangoproject.com/ticket/16922. Reviewing the past discussion may help you refine your proposal. On Friday, February 3, 2017 at 6:01:11 AM UTC-5, Gert Steyn wrote: > > Hi All > > Is anybody against using the new renderers (used to render widget

Re: Implement form.as_table, as_ul, as_p using templates

2017-02-03 Thread Gert Steyn
Hi Tim The implementation can be extremely simple as most of the heavy lifting has already been done for widget templates. The only new parts are: 1. BaseForm.get_context 2. The templates to implement as_table, as_ul and as_p 3. A little bit of glue (render etc, pretty much the same as

Added signals that runs when adding an object to a Many-To-One relation

2017-02-03 Thread Oskar Persson
Hi everyone. I've created a pull request (8018) that adds the signals pre_add and post_add that are triggered when adding an object to a Many-To-One relation. The reason for this PR is to provide a simple (is there any other?) way to run custom code

Re: Added signals that runs when adding an object to a Many-To-One relation

2017-02-03 Thread Paul Egges
I thought a Many-To-One would not require an intermediate table, so it would be caught by pre-save and post-save on the object containing the Foreign Key. Is that not true? Paul On Fri, Feb 3, 2017 at 8:28 AM, Oskar Persson wrote: > Hi everyone. > > I've created a pull request (8018) >

Re: Added signals that runs when adding an object to a Many-To-One relation

2017-02-03 Thread Oskar Persson
No, the save method isn't called unless you specify bulk=False Den fredag 3 februari 2017 kl. 17:53:04 UTC+1 skrev mtnpaul: > > I thought a Many-To-One would not require an intermedia

Re: Added signals that runs when adding an object to a Many-To-One relation

2017-02-03 Thread Paul Egges
Good to know. Thanks, Paul On Fri, Feb 3, 2017 at 10:03 AM, Oskar Persson wrote: > No, the save method isn't called unless you specify bulk=False > > > Den fredag 3 februari 2017

Re: Added signals that runs when adding an object to a Many-To-One relation

2017-02-03 Thread Tim Graham
#21461 proposes to add signals for QuerySet.update(). Would this solve your use case? https://code.djangoproject.com/ticket/21461 On Friday, February 3, 2017 at 12:14:23 PM UTC-5, mtnpaul wrote: > > Good to know. > > Thanks, > > Paul > > > On Fri, Feb 3, 2017 at 10:03 AM, Oskar Persson > wrote

Re: Added signals that runs when adding an object to a Many-To-One relation

2017-02-03 Thread Oskar Persson
It would. Though that seems like its trying to solve a bigger issue since then you probably *need* the updated objects, which I'm not including Den fredag 3 februari 2017 kl. 18:21:55 UTC+1 skrev Tim Graham: > > #21461 proposes to add signals for QuerySet.update(). Would this solve > your use ca

Re: Implement form.as_table, as_ul, as_p using templates

2017-02-03 Thread Josh Smeaton
I like the concept, though I haven't looked into the 4 points you laid out. I like the concept of the prefix you mentioned in the widget thread also - I'd love to see template packs as third party libraries that easily slot in (per form I think is crucial). I'm unsure of the proposed properties