Re: Customizing context by opening up BoundField, is it ok?
On Jul 23, 12:41 am, Russell Keith-Magee wrote: > The decision about splitting this into more than one view is > approaching an 'inmates running the asylum' issue [1]. Work out what > UI will work for your users. Then work out how to make that > implementation work. Don't let the implementation drive the UI. > > [1]http://www.amazon.com/Inmates-Are-Running-Asylum/dp/0672316498 Oh ya, I bought the book too. :o) I think I have a tendency to find myself in this trap. --~--~-~--~~~---~--~~ 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: Customizing context by opening up BoundField, is it ok?
On Jul 23, 12:41 am, Russell Keith-Magee wrote: > This sounds like you are on the right track. My only other suggestion > is that it might be worth looking into using FormSets to simplify the > logic for displaying multiple Payment forms on the page. Thanks for your input. Just to give you an update. I ended up not using FormSets. They seem to be more geared toward a single save button for the page and I wanted to force them to save each payment individually. Tthe feedback is quick and it comes across as the line just changing from editable to not. Though it was good to review the FormSets. I think I'm just about ready for testing. I just have a few for strange bugs to work out, like why the errors output isn't being wrapped in a ul tag. I think I can see the light. :o) Thanks again for your time. --~--~-~--~~~---~--~~ 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: Customizing context by opening up BoundField, is it ok?
On Thu, Jul 23, 2009 at 3:51 AM, Joshua Russo wrote:
> On Wed, Jul 22, 2009 at 10:51 AM, Russell Keith-Magee
> 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).
>
> 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.
...
> 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.
This sounds like you are on the right track. My only other suggestion
is that it might be worth looking into using FormSets to simplify the
logic for displaying multiple Payment forms on the page.
The decision about splitting this into more than one view is
approaching an 'inmates running the asylum' issue [1]. Work out what
UI will work for your users. Then work out how to make that
implementation work. Don't let the implementation drive the UI.
[1] http://www.amazon.com/Inmates-Are-Running-Asylum/dp/0672316498
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
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Customizing context by opening up BoundField, is it ok?
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
-~--~~~~--~~--~--~---
Re: Customizing context by opening up BoundField, is it ok?
On Wed, Jul 22, 2009 at 3:46 AM, Joshua Russo wrote: > > I have a complex form that where I generate a grid (for lack of a > better term) of fields for data entry. To simplify the template > context I have a dictionaries within dictionaries so I can just use > FOR loops within FOR loops in the template. > > My problem was that, unless I wrapped my fields in a BoundField, I > would only receive the field's object reference output instead of the > rendered widgets. So I added BoundField to the list of available > objects in forms.py and everything is hums along merrily. > > My question is, am I breaking any Django commandments by opening up > the BoundField (other than not monkey patching)? Firstly, the "Django Commandments" are really just "being Pythonic". Django is just a python library - we don't try to enforce any style beyond that encouraged by the language itself. Monkeypatching is discouraged because Python generally discourages it, not because Django discourages it. 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. 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 django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
