On Wed, Jul 22, 2009 at 10:51 AM, Russell Keith-Magee <
freakboy3...@gmail.com> wrote:
>
> Secondly, it's difficult to give an appraisal of a technique when all
> you have to go by is a vague description. Your explanation is a bit
> hard to follow - you talk at length about fields, but don't mention
> the form that holds those fields. Then you talk about the lengths you
> have gone to in order to expose BoundField ... but don't appear to
> acknowledge that if you iterate over the fields in a form, what you
> get are instances of BoundField. I can appreciate that code can get in
> the way of understanding a broader idea, but sometimes, a small amount
> of code brings a lot of clarity.


Sorry for the cryptic explanation. I think I was a little self conscious
about how complex this form was getting and thought that people would skip
on by to the next post if I gave too much info. Anyway, here's the structure
that I'm working with. I have lists of people, properties, and payments.
(Side note: The application is for a Portuguese speaking community and I've
used some of the language in the code because I'm not going to be the one
maintaining the app over the long term.)

class Pessoa(models.Model):
    """
    A person who is responsible for paying taxes.
    """
    id          = models.IntegerField('Número',
primary_key=True, blank=True)
    Nome        = models.CharField('Nome', max_length=100)
    ...

class Matriz(models.Model):
    """
    Locales where a person needs to pay taxes
    """
    NumOrd        = models.IntegerField('Número',
primary_key=True, blank=True)
    SitPredios    = AutoCompleteCharField('Situação dos prédios',
max_length=50)
    ...

class MatrizPagamento(models.Model):
    """
    Payments for a Matriz
    """
    NumOrd     = models.ForeignKey(Matriz)
    Pessoa     = models.ForeignKey(Pessoa)
    Quantia = CurrencyField('Quantidade paga', max_digits=15)
    Ano     = models.IntegerField('Ano',
default=datetime.datetime.today().year)
    ...

I only have one view outside of the admin app and generic views I use for
reports. This view starts very simply with a field to select a person
(Pessoa) (I created a couple of util functions/classes to be able to use the
ForeignKeySearch field outside of the admin app because I liked the popup)

Once they select a person it shows them all of their valid properties
(Matriz) and if any of them need payment. If a payment is due then they can
edit and save the amount with a save button for each row/payment. In my
template context I have a property list (matrizList) and for each entry in
that I have a payment list. It's in the payment list that I wanted to use
BoundField because it would be easier that trying to reference the field in
the standard list of fields. I had to give each a unique name and so doing
contextually (in my payment list) was much easier than recreating the name
in the template syntax (I'm not even sure if I could have).

You can see how things got a little complex, and at first I completely
bypassed the built-in forms functionality and did *everything*  for the
view. Then I started to think about unit testing and my head exploded.

What I've arrived at today is actually using multiple forms (and no longer
need BoundField). Each payment row is it's own form and then I check to see
which type of button they used to submit and create form objects
accordingly.

This seems to work well. I have two form objects, my primary search form and
a payment form. Tho I'm still working through were to put the code that
generates the list of properties and payments. It's currently in the init
for the search form, but I will probably move that out into the view
tomorrow.

Does this sound reasonable, or am I still over thinking the plumbing? I get
the nagging impression I should just bite the bullet and split this into
more than one view.

Thanks for your advice
Josh

--~--~---------~--~----~------------~-------~--~----~
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