Re: Confusion over CRUD generic views and newforms
Thanks Phil. Seems to do exactly what it promises. Regards, Matt. On Jul 29, 12:10 pm, "Phil Davis" <[EMAIL PROTECTED]> wrote: > On 26/07/07, Matt <[EMAIL PROTECTED]> wrote: > > > Can you confirm that the CRUDgenericviewsare compatible with > >newforms? I haven't seen any examples of how to do it, but I'm having > > a hard time believing that this core functionality hasn't been > > implemented (or even patched) fornewformsyet. > > You may want to look at: > > http://www.djangosnippets.org/snippets/99/ > > which is a re-implementation of create_object and > update_objectgenericviewsusingnewformsby danjak. > > I have not actually tried using the code though and it does not look > like it supports thenewformsedit_inline stuff (not surprising as > written before that appeared). > > -- > Phil --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Confusion over CRUD generic views and newforms
On 26/07/07, Matt <[EMAIL PROTECTED]> wrote: > Can you confirm that the CRUD generic views are compatible with > newforms? I haven't seen any examples of how to do it, but I'm having > a hard time believing that this core functionality hasn't been > implemented (or even patched) for newforms yet. You may want to look at: http://www.djangosnippets.org/snippets/99/ which is a re-implementation of create_object and update_object generic views using newforms by danjak. I have not actually tried using the code though and it does not look like it supports the newforms edit_inline stuff (not surprising as written before that appeared). -- Phil --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Confusion over CRUD generic views and newforms
On 7/27/07, Matt <[EMAIL PROTECTED]> wrote: > > 3693 is marked as 'accepted' - does that mean that its changes are in > trunk? No - it means that this is a change that we want to make, but haven't yet. Usually it means that there isn't a patch available, or that the patch isn't correct. In this case, as Malcolm's comment notes, it means that the patch can't be applied until FileFields are implemented. FileFields (#3297) is one area that is on my to-do list; I had a working patch a few weeks back, but I got dragged away from Django by work, and I lost track of the discussion around the ticket. I hope to get back to the ticket in the near future. > Since I'm just starting out with Django, I'm loathe to learn oldforms > only to have to redo my work when the next release comes out. The CRUD > generic views seem so useful - I'll be amazed if there's not a working > newforms solution out there somewhere. One source to look at is the newforms-admin branch. This branch contains many form-related changes that haven't made it in to the trunk yet. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Confusion over CRUD generic views and newforms
> The CRUD generic views are using oldforms AFAIK. Patches 3639 (http://code.djangoproject.com/ticket/3639) and 4636 (http://code.djangoproject.com/ticket/4236) seem to address this problem, but I've not had any luck applying them. 3693 is marked as 'accepted' - does that mean that its changes are in trunk? Otherwise, how do you know which version each patch applies to? When I tried to apply 3639 to 0.96 I got errors about 'forms.models.form_from_model' not existing. Since I'm just starting out with Django, I'm loathe to learn oldforms only to have to redo my work when the next release comes out. The CRUD generic views seem so useful - I'll be amazed if there's not a working newforms solution out there somewhere. If anyone knows please enlighten me! Thanks, Matt. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Confusion over CRUD generic views and newforms
On Jul 26, 4:50 pm, Matt <[EMAIL PROTECTED]> wrote:
> Hi Etienne,
>
> I read that {{ form.as_table }} was the default value for {{ form }}
> as well, but when I insert {{ form }} into my template I get something
> out which looks like the output of a __str__ method - a list of
> dictionaries and values.
>
> I'm running Python 2.5 on Ubuntu Feisty. I'll put together a test on a
> Windows box later today and see if I still have the same problems.
>
> Can you confirm that the CRUD generic views are compatible with
> newforms? I haven't seen any examples of how to do it, but I'm having
> a hard time believing that this core functionality hasn't been
> implemented (or even patched) for newforms yet.
The CRUD generic views are using oldforms AFAIK.
> Thanks,
> Matt.
>
> On Jul 26, 12:19 am, "Etienne Robillard" <[EMAIL PROTECTED]>
> wrote:
>
> > I think the default value for {{ form }} is {{ form.as_table }}, so
> > perhaps it is safe to just use the default {{ form }} within a
> > table element:
>
> >
> >
> > {{ form }}
> >
> >
>
> > As for this error, it looks like the server didnt finished serving a request
> > and crashed. Maybe upgrading Python and a couple of python modules
> > should help.
>
> > Regards,
> > Etienne
>
> > On 7/25/07, Matt <[EMAIL PROTECTED]> wrote:
>
> > > Eric,
>
> > > It seems I jumped to conclusions too quickly. I'm finding that
> > > {{ form.as_table }}, {{ form.as_ul }} and {{ form.as_p }} cause the
> > > server to error. The page is still served, but the following is in the
> > > terminal where the development server is running:
>
> > > Traceback (most recent call last):
> > > File "/usr/lib/python2.5/site-packages/django/core/servers/
> > > basehttp.py", line 279, in run
> > > self.finish_response()
> > > File "/usr/lib/python2.5/site-packages/django/core/servers/
> > > basehttp.py", line 318, in finish_response
> > > self.write(data)
> > > File "/usr/lib/python2.5/site-packages/django/core/servers/
> > > basehttp.py", line 397, in write
> > > self.send_headers()
> > > File "/usr/lib/python2.5/site-packages/django/core/servers/
> > > basehttp.py", line 449, in send_headers
> > > self.send_preamble()
> > > File "/usr/lib/python2.5/site-packages/django/core/servers/
> > > basehttp.py", line 379, in send_preamble
> > > 'Date: %s\r\n' % (formatdate()[:26] + "GMT")
> > > File "socket.py", line 262, in write
> > > self.flush()
> > > File "socket.py", line 249, in flush
> > > self._sock.sendall(buffer)
> > > error: (32, 'Broken pipe')
>
> > > This is occurring with the SVN version of Django. Have you seen this
> > > before?
>
> > > Thanks,
> > > Matt.- Hide quoted text -
>
> > - Show quoted text -
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Confusion over CRUD generic views and newforms
Hi Etienne,
I read that {{ form.as_table }} was the default value for {{ form }}
as well, but when I insert {{ form }} into my template I get something
out which looks like the output of a __str__ method - a list of
dictionaries and values.
I'm running Python 2.5 on Ubuntu Feisty. I'll put together a test on a
Windows box later today and see if I still have the same problems.
Can you confirm that the CRUD generic views are compatible with
newforms? I haven't seen any examples of how to do it, but I'm having
a hard time believing that this core functionality hasn't been
implemented (or even patched) for newforms yet.
Thanks,
Matt.
On Jul 26, 12:19 am, "Etienne Robillard" <[EMAIL PROTECTED]>
wrote:
> I think the default value for {{ form }} is {{ form.as_table }}, so
> perhaps it is safe to just use the default {{ form }} within a
> table element:
>
>
>
> {{ form }}
>
>
>
> As for this error, it looks like the server didnt finished serving a request
> and crashed. Maybe upgrading Python and a couple of python modules
> should help.
>
> Regards,
> Etienne
>
> On 7/25/07, Matt <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> > Eric,
>
> > It seems I jumped to conclusions too quickly. I'm finding that
> > {{ form.as_table }}, {{ form.as_ul }} and {{ form.as_p }} cause the
> > server to error. The page is still served, but the following is in the
> > terminal where the development server is running:
>
> > Traceback (most recent call last):
> > File "/usr/lib/python2.5/site-packages/django/core/servers/
> > basehttp.py", line 279, in run
> > self.finish_response()
> > File "/usr/lib/python2.5/site-packages/django/core/servers/
> > basehttp.py", line 318, in finish_response
> > self.write(data)
> > File "/usr/lib/python2.5/site-packages/django/core/servers/
> > basehttp.py", line 397, in write
> > self.send_headers()
> > File "/usr/lib/python2.5/site-packages/django/core/servers/
> > basehttp.py", line 449, in send_headers
> > self.send_preamble()
> > File "/usr/lib/python2.5/site-packages/django/core/servers/
> > basehttp.py", line 379, in send_preamble
> > 'Date: %s\r\n' % (formatdate()[:26] + "GMT")
> > File "socket.py", line 262, in write
> > self.flush()
> > File "socket.py", line 249, in flush
> > self._sock.sendall(buffer)
> > error: (32, 'Broken pipe')
>
> > This is occurring with the SVN version of Django. Have you seen this
> > before?
>
> > Thanks,
> > Matt.- Hide quoted text -
>
> - Show quoted text -
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Confusion over CRUD generic views and newforms
I think the default value for {{ form }} is {{ form.as_table }}, so
perhaps it is safe to just use the default {{ form }} within a
table element:
{{ form }}
As for this error, it looks like the server didnt finished serving a request
and crashed. Maybe upgrading Python and a couple of python modules
should help.
Regards,
Etienne
On 7/25/07, Matt <[EMAIL PROTECTED]> wrote:
>
>
> Eric,
>
> It seems I jumped to conclusions too quickly. I'm finding that
> {{ form.as_table }}, {{ form.as_ul }} and {{ form.as_p }} cause the
> server to error. The page is still served, but the following is in the
> terminal where the development server is running:
>
> Traceback (most recent call last):
> File "/usr/lib/python2.5/site-packages/django/core/servers/
> basehttp.py", line 279, in run
> self.finish_response()
> File "/usr/lib/python2.5/site-packages/django/core/servers/
> basehttp.py", line 318, in finish_response
> self.write(data)
> File "/usr/lib/python2.5/site-packages/django/core/servers/
> basehttp.py", line 397, in write
> self.send_headers()
> File "/usr/lib/python2.5/site-packages/django/core/servers/
> basehttp.py", line 449, in send_headers
> self.send_preamble()
> File "/usr/lib/python2.5/site-packages/django/core/servers/
> basehttp.py", line 379, in send_preamble
> 'Date: %s\r\n' % (formatdate()[:26] + "GMT")
> File "socket.py", line 262, in write
> self.flush()
> File "socket.py", line 249, in flush
> self._sock.sendall(buffer)
> error: (32, 'Broken pipe')
>
> This is occurring with the SVN version of Django. Have you seen this
> before?
>
> Thanks,
> Matt.
>
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Confusion over CRUD generic views and newforms
Eric,
It seems I jumped to conclusions too quickly. I'm finding that
{{ form.as_table }}, {{ form.as_ul }} and {{ form.as_p }} cause the
server to error. The page is still served, but the following is in the
terminal where the development server is running:
Traceback (most recent call last):
File "/usr/lib/python2.5/site-packages/django/core/servers/
basehttp.py", line 279, in run
self.finish_response()
File "/usr/lib/python2.5/site-packages/django/core/servers/
basehttp.py", line 318, in finish_response
self.write(data)
File "/usr/lib/python2.5/site-packages/django/core/servers/
basehttp.py", line 397, in write
self.send_headers()
File "/usr/lib/python2.5/site-packages/django/core/servers/
basehttp.py", line 449, in send_headers
self.send_preamble()
File "/usr/lib/python2.5/site-packages/django/core/servers/
basehttp.py", line 379, in send_preamble
'Date: %s\r\n' % (formatdate()[:26] + "GMT")
File "socket.py", line 262, in write
self.flush()
File "socket.py", line 249, in flush
self._sock.sendall(buffer)
error: (32, 'Broken pipe')
This is occurring with the SVN version of Django. Have you seen this
before?
Thanks,
Matt.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Confusion over CRUD generic views and newforms
On 25 Lip, 21:38, Matt <[EMAIL PROTECTED]> wrote: > Hi Eric, > > Unfortunately neither of those seem to do anything - the template > seems to just skip over it. I first tried with the 0.96 release, and I > have updated to the SVN version with the same result. > > Any idea what I'm doing wrong? No cristal ball here... Show us some more code, for example how is your form defined etc. -- Jakub Wisniowski --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Confusion over CRUD generic views and newforms
Hi Eric,
Unfortunately neither of those seem to do anything - the template
seems to just skip over it. I first tried with the 0.96 release, and I
have updated to the SVN version with the same result.
Any idea what I'm doing wrong?
Thanks,
Matt.
On Jul 25, 6:55 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> Hello,
>
> {{ form.as_ul }} or {{ form.as_table }}, etc, should work for this
> purpose.
>
> Hope that helps,
> Eric
>
> Matt wrote:
> > Hello group,
>
> > I'm reasonably new to Django andconfused over how to implement generic
> > views for CRUD operations, specifically with respect to newforms. I'm
> > using 0.96 for the time being, but I'm happy to upgrade to the
> > development version if required.
>
> > What I'm trying to acheive is an automatic way of rendering a form to
> > create/update etc. a model. I know this is possible because the admin
> > site does it!
>
> > I understand how the URLconf part of things work, but I'm not sure
> > what to put in the template to actually render the form.
>
> > For completeness, my URLconf contains this line:
>
> > > (r'^job/new/$', create_object, {'model': Job, 'template_name':
> > > 'newjob.html'}),
>
> > and my (very simplistic) template contains this:
>
> > > {% block content %}
> > > Fill in this form:
> > > {{form}}
> > > {% endblock %}
>
> > I had hoped that some magic would turn {{form}} into an HTML rendered
> > form, but all it does it output the __str__ method of FormWrapper.
>
> > If I use {{form.field}}, then the field is correctly rendered in the
> > HTML - but it seems stupidly repetitive to have to manually rebuild
> > forms in the template using {{form.field}} for every field. So my
> > first question is: how can this be done automatically?
>
> > Secondly, am I shooting myself in the foot here by using elements of
> > oldforms which will be canned in the next stable release? And if so,
> > are there any resources out there on how to do this the 'right' way?
>
> > Many thanks indeed,
> > Matt.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Confusion over CRUD generic views and newforms
Hello,
{{ form.as_ul }} or {{ form.as_table }}, etc, should work for this
purpose.
Hope that helps,
Eric
Matt wrote:
> Hello group,
>
> I'm reasonably new to Django andconfused over how to implement generic
> views for CRUD operations, specifically with respect to newforms. I'm
> using 0.96 for the time being, but I'm happy to upgrade to the
> development version if required.
>
> What I'm trying to acheive is an automatic way of rendering a form to
> create/update etc. a model. I know this is possible because the admin
> site does it!
>
> I understand how the URLconf part of things work, but I'm not sure
> what to put in the template to actually render the form.
>
> For completeness, my URLconf contains this line:
>
> > (r'^job/new/$', create_object, {'model': Job, 'template_name':
> > 'newjob.html'}),
>
> and my (very simplistic) template contains this:
>
> > {% block content %}
> > Fill in this form:
> > {{form}}
> > {% endblock %}
>
> I had hoped that some magic would turn {{form}} into an HTML rendered
> form, but all it does it output the __str__ method of FormWrapper.
>
> If I use {{form.field}}, then the field is correctly rendered in the
> HTML - but it seems stupidly repetitive to have to manually rebuild
> forms in the template using {{form.field}} for every field. So my
> first question is: how can this be done automatically?
>
> Secondly, am I shooting myself in the foot here by using elements of
> oldforms which will be canned in the next stable release? And if so,
> are there any resources out there on how to do this the 'right' way?
>
> Many thanks indeed,
> Matt.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Confusion over CRUD generic views and newforms
Hello group,
I'm reasonably new to Django andconfused over how to implement generic
views for CRUD operations, specifically with respect to newforms. I'm
using 0.96 for the time being, but I'm happy to upgrade to the
development version if required.
What I'm trying to acheive is an automatic way of rendering a form to
create/update etc. a model. I know this is possible because the admin
site does it!
I understand how the URLconf part of things work, but I'm not sure
what to put in the template to actually render the form.
For completeness, my URLconf contains this line:
> (r'^job/new/$', create_object, {'model': Job, 'template_name':
> 'newjob.html'}),
and my (very simplistic) template contains this:
> {% block content %}
> Fill in this form:
> {{form}}
> {% endblock %}
I had hoped that some magic would turn {{form}} into an HTML rendered
form, but all it does it output the __str__ method of FormWrapper.
If I use {{form.field}}, then the field is correctly rendered in the
HTML - but it seems stupidly repetitive to have to manually rebuild
forms in the template using {{form.field}} for every field. So my
first question is: how can this be done automatically?
Secondly, am I shooting myself in the foot here by using elements of
oldforms which will be canned in the next stable release? And if so,
are there any resources out there on how to do this the 'right' way?
Many thanks indeed,
Matt.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
