Re: form new versus edit

[br]

My HTML guy and designer tend to get together to do some fancy stuff
(read: pain in the butt) so sometimes I need to access the data that a
model form field represents and can't just let django render it, which
is obviously the preferred way and I go that way if possible.  I am
pretty knew to this, but i figured that a custom tag filter could do
the trick, given that the data is in different places for an unbound
model form vs a form that is bound.  (would be a nice feature to have
one variable or attribute to access that would always have it, but
there seems to be resistance to this.)  This seems to work for my use
cases, but I haven't tested extensively so use at your own risk and
YMMV.  (put this in a python file in a templatetags directory in your
app and make sure you load the tags . . .read the docs)

@register.filter(name='modelform_field_value')
def modelform_field_value(value, arg):
"""
Usage: | model_field_value : ""
Returns the value of a field in a ModelForm, regardless of whether
the ModelForm was loaded with a Model Instance or with POST data
"""

form = value
field_name = arg
try:
if form.data.get(field_name) != None:
return  getattr(form.data, field_name)
# post data takes priority over instance data (this is useful
when is_valid is false and a form is returned to the template for
errors to be displayed, wherein both form and instance exist, but the
post is the most recent)
else:
return getattr(form.instance, field_name)
except Exception as e:
logger.error("Error in modelform_field_value tag.  Unable to
get value for field %s in form %s. \n%s"  %(field_name, form, str(e))
return "" # Best to log the error and display nothing than
letting the server throw a 500 or putting up something incorrect.

As far as getting the id in a hidden field,

you can use something like when you define your form:

class MyForm:

class Meta:
model = MyModel
fields = ('id', )
widgets = {
  'id': HiddenInput(),
 
}

or you could do something like this:

id  = IntegerField(
   widget = HiddenInput (attrs = {'class':'some-
class'}))


My experience has been that working with forms was the most
challenging part of Django to learn, decipher and figure out,
particularly if you don't want to let django render forms in a
default, simple way, which if you're working with Web 2.0 mentality
designers, where everything is "ajaxy", is rarely the case.  But after
learning enough to make django forms work for me with their designs, i
highly recommend defining your fields on the django side, because it
makes all of the backend stuff: processing, validation, writing to db,
etc. etc.  so so much easier and less error prone.  I typically only
use the above tag if i am just rendering some static text or anchor
tag, or checking if a value exists or equals something in template tag
logic. If its a form element, i try to define it in django.

Ben


On May 14, 4:45 pm, Greg Donald  wrote:
> On Sat, May 14, 2011 at 5:20 PM, Shawn Milochik  wrote:
> > One way:
>
> > class CustomCharField(forms.CharField):
>
> >     def __init__(self, *args, **kwargs):
>
> >     super(CustomCharField, self).__init__(*args, **kwargs)
>
> >     self.widget=forms.TextInput(attrs={ 'class':'myclass' })
>
> > class MyForm(forms.Form):
>
> >     field1 = forms.CustomCharField()
> >     field2 = forms.CustomCharField()
>
> Thank you.
>
> What is the convention for getting a pk id into a hidden form field?
>
> Since {{ form.name }} is the convention for getting my name field HTML
> rendered, I naturally tried {{ form.id }}, but it doesn't seem to know
> about Django conventions I don't guess.
>
> --
> Greg Donald
> destiney.com | gregdonald.com

-- 
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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: form new versus edit

[Greg Donald]

On Sat, May 14, 2011 at 5:20 PM, Shawn Milochik  wrote:
> One way:
>
> class CustomCharField(forms.CharField):
>
>     def __init__(self, *args, **kwargs):
>
>     super(CustomCharField, self).__init__(*args, **kwargs)
>
>     self.widget=forms.TextInput(attrs={ 'class':'myclass' })
>
>
> class MyForm(forms.Form):
>
>     field1 = forms.CustomCharField()
>     field2 = forms.CustomCharField()


Thank you.

What is the convention for getting a pk id into a hidden form field?

Since {{ form.name }} is the convention for getting my name field HTML
rendered, I naturally tried {{ form.id }}, but it doesn't seem to know
about Django conventions I don't guess.


-- 
Greg Donald
destiney.com | gregdonald.com

-- 
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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: form new versus edit

[Shawn Milochik]

On 05/14/2011 06:09 PM, Greg Donald wrote:

 On Sat, May 14, 2011 at 4:58 PM, Shawn Milochik 
 wrote:
> This isn't a case of "our way rules and if you disagree then you
> suck." I just wanted to make sure you don't walk away with that
> impression.


 How can I set this same widget value

 name = CharField( widget=TextInput( attrs={ 'class':'myclass' } ) )

 in a single place for all my CharField types?





One way:


class CustomCharField(forms.CharField):

def __init__(self, *args, **kwargs):

super(CustomCharField, self).__init__(*args, **kwargs)

self.widget=forms.TextInput(attrs={ 'class':'myclass' })


class MyForm(forms.Form):

field1 = forms.CustomCharField()
field2 = forms.CustomCharField()



--
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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: form new versus edit

[Greg Donald]

On Sat, May 14, 2011 at 4:58 PM, Shawn Milochik  wrote:
> This isn't a case of "our way rules and if you disagree then you suck." I
> just wanted to make sure you don't walk away with that impression.


How can I set this same widget value

name = CharField( widget=TextInput( attrs={ 'class':'myclass' } ) )

in a single place for all my CharField types?



-- 
Greg Donald
destiney.com | gregdonald.com

-- 
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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: form new versus edit

[Shawn Milochik]

On 05/14/2011 05:47 PM, Greg Donald wrote:

On Sat, May 14, 2011 at 4:39 PM, Shawn Milochik  wrote:

I'm certain there are plenty of reasons that others could chime in with. In
any case, you're free to do it however you like. But if you choose to use
Django, be aware of the fact that a huge amount of thought has gone into the
project, and if something's there it's probably for a really good reason.
When you choose not to follow a Django convention and run into a problem
then don't be surprised.

I didn't realize trying to access my own form data directly was
unconventional, my bad.



Again, if there's anything you want to do that you can't because of the 
way something in Django works, just ask.


The whole point of a Web framework is to save you (the developer) the 
hassle of doing all the routine junk, such as validating/sanitizing 
input, re-drawing forms with errors for user correction, writing SQL, 
etc. It's always good to know how it's working and have the ability to 
tweak it, as you obviously do. But as long as you have that to fall back 
on it's best to let Django do the heavy (or boring) lifting for you 
whenever possible.


This isn't a case of "our way rules and if you disagree then you suck." 
I just wanted to make sure you don't walk away with that impression.


Shawn


--
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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: form new versus edit

[Greg Donald]

On Sat, May 14, 2011 at 4:39 PM, Shawn Milochik  wrote:
> I'm certain there are plenty of reasons that others could chime in with. In
> any case, you're free to do it however you like. But if you choose to use
> Django, be aware of the fact that a huge amount of thought has gone into the
> project, and if something's there it's probably for a really good reason.
> When you choose not to follow a Django convention and run into a problem
> then don't be surprised.

I didn't realize trying to access my own form data directly was
unconventional, my bad.


-- 
Greg Donald
destiney.com | gregdonald.com

-- 
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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: form new versus edit

[Shawn Milochik]

On 05/14/2011 05:33 PM, Greg Donald wrote:

On Sat, May 14, 2011 at 4:22 PM, Daniel Roseman  wrote:

Which is what Shawn said. If you follow the pattern described in the
excellent documentation, you'll see that there's no reason to try and
reference the form's data, as the form will re-render itself anyway if
validation fails. And there's no reason to have separate templates or views
for add and edit.

So the fact that form.name.data is set sometimes but not others is not
a bug?  Seems like a bug to me.  Why is it set at all if accessing it
isn't the preferred way?

So OK, if I do use {{ form.name }} then I have to set CSS attributes
for every field using:

name = forms.CharField( widget=forms.TextInput(attrs={'class':'special'}))

How is that better than just writing a simple  field myself?


There are a lot of benefits, beginning with the fact that doing it once 
in your Form class is a lot better than doing it in each template.


Secondly, if you ever use a prefix with your form or use a formset, then 
writing your own raw HTML elements is going to bite you hard.


I'm certain there are plenty of reasons that others could chime in with. 
In any case, you're free to do it however you like. But if you choose to 
use Django, be aware of the fact that a huge amount of thought has gone 
into the project, and if something's there it's probably for a really 
good reason. When you choose not to follow a Django convention and run 
into a problem then don't be surprised.


Shawn


--
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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: form new versus edit

[Greg Donald]

On Sat, May 14, 2011 at 4:22 PM, Daniel Roseman  wrote:
> Which is what Shawn said. If you follow the pattern described in the
> excellent documentation, you'll see that there's no reason to try and
> reference the form's data, as the form will re-render itself anyway if
> validation fails. And there's no reason to have separate templates or views
> for add and edit.

So the fact that form.name.data is set sometimes but not others is not
a bug?  Seems like a bug to me.  Why is it set at all if accessing it
isn't the preferred way?

So OK, if I do use {{ form.name }} then I have to set CSS attributes
for every field using:

name = forms.CharField( widget=forms.TextInput(attrs={'class':'special'}))

How is that better than just writing a simple  field myself?


-- 
Greg Donald
destiney.com | gregdonald.com

-- 
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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: form new versus edit

[Daniel Roseman]

On Saturday, 14 May 2011 22:14:38 UTC+1, Greg Donald wrote:
>
> On Sat, May 14, 2011 at 4:08 PM, Shawn Milochik  
> wrote:
> > The problem is that you're doing this at all. You should instead be using 
> {{
> > form.name }} to put the field in the form.
>
>
> Well that works for the vanilla case but I need access to the data.
>
>
> -- 
> Greg Donald
>
Which is what Shawn said. If you follow the pattern described in the 
excellent documentation, you'll see that there's no reason to try and 
reference the form's data, as the form will re-render itself anyway if 
validation fails. And there's no reason to have separate templates or views 
for add and edit.
--
DR.

-- 
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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: form new versus edit

[Shawn Milochik]

On 05/14/2011 05:14 PM, Greg Donald wrote:

On Sat, May 14, 2011 at 4:08 PM, Shawn Milochik  wrote:

On 05/14/2011 05:04 PM, Greg Donald wrote:

I have a "new" contact form.  If I post it, and it has error, I found
(while debugging, not documented that I can find) that I can redraw
the submitted form data using form.name.data like this:





The problem is that you're doing this at all. You should instead be using {{
form.name }} to put the field in the form.


Well that works for the vanilla case but I need access to the data.



What do you need to do that this makes difficult?

--
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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: form new versus edit

[Greg Donald]

On Sat, May 14, 2011 at 4:08 PM, Shawn Milochik  wrote:
> On 05/14/2011 05:04 PM, Greg Donald wrote:
>>
>> I have a "new" contact form.  If I post it, and it has error, I found
>> (while debugging, not documented that I can find) that I can redraw
>> the submitted form data using form.name.data like this:
>>
>> 
>
> 
>
> The problem is that you're doing this at all. You should instead be using {{
> form.name }} to put the field in the form.


Well that works for the vanilla case but I need access to the data.


-- 
Greg Donald
destiney.com | gregdonald.com

-- 
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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: form new versus edit

[Shawn Milochik]

On 05/14/2011 05:04 PM, Greg Donald wrote:

I have a "new" contact form.  If I post it, and it has error, I found
(while debugging, not documented that I can find) that I can redraw
the submitted form data using form.name.data like this:





The problem is that you're doing this at all. You should instead be 
using {{ form.name }} to put the field in the form.


This will work in either case.

--
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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

form new versus edit

[Greg Donald]

I have a "new" contact form.  If I post it, and it has error, I found
(while debugging, not documented that I can find) that I can redraw
the submitted form data using form.name.data like this:



But, if I use that same form model in my "edit" contact form,
form.name.data is None.  Why is that?


In my new method I do:

form = ContactForm( request.POST )


In my edit method I do:

contact = Contact.objects.get( pk=id )
form = ContactForm( instance=contact )

But then the form contains none of the fields I'm expecting, form.name
simply isn't there so form.name.data throws an exception.


What am I doing wrong?

I'd really like to just have my one _form.html template included in
both my add.html and my edit.html templates.  How can I do that when
the form doesn't even work the same between new versus editing?


Thanks.


-- 
Greg Donald
destiney.com | gregdonald.com

-- 
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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.