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:    <form> | model_field_value : "<field name>"
    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', <other fields here>)
        widgets = {
                  'id': HiddenInput(),
                 <other custom widgets, if any >
                }

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 <gdon...@gmail.com> wrote:
> On Sat, May 14, 2011 at 5:20 PM, Shawn Milochik <sh...@milochik.com> 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.

Reply via email to