Unless things have changed, the trouble is that the individual bound fields aren't all in existence at the same time, but are created and discarded one at a time as the outer widget iterates the choices. I once uploaded a snippet for a template tag that performed the iteration, allowing finer styling control. I've forgotten the details, or the pointer to my snippet, but such a tag could let you iterate template code for each button, rendering what you want, having recognized, say, the value of the button field that you want to render differently in a template ifequal, or equivalent. Of course you are also then stuck with self rendering the whole Form, unless you put everything else in one Form, and this in another, but all within the same "form" tag so that they are submitted together. Your view needs to be aware of the two forms. But at this point you could just separately render the list of choices by hand, leaving the Choice field out of the Form's fields list. I always put my choices lists as Model attributes, so I can make them easily accessible in the template, though a suitable iterator method on the Model makes the template code cleaner.
I'm liking the last approach best in that things like my template tag had to dip into Field internals, so it is fragile across Django versions, while rendering the special radio collection by hand fits the "explicit is better than implicit (magic)" mantra, and doesn't use anything that is likely to change out from under you. (Though adding a suitable iterator method on Choice/MultiChoice Fields to the API would not be unwelcome.) Bill On Thu, Jul 14, 2011 at 3:10 PM, NateB <nate.br...@adb-air.com> wrote: > > > CrabbyPete wrote: >> >> I am trying to do the same thing. Did you ever get a response? >> > > I accepted an answer to the one on the stack overflow question I linked to > in my previous email - however, it wasn't what I was *really* hoping for > (although it definitely works). Before asking, I spent a long time > searching through the Django code, and I couldn't come up with a clean > solution (but figured that it was simply my ignorance, because I considered > that a weird oversight). I get the impression now that there *is* no easy, > pretty way of doing it, just a circuitous, not-so-pretty way of doing it. > -- > View this message in context: > http://old.nabble.com/django-form-radio-input-layout-tp31862033p32063704.html > Sent from the django-users mailing list archive at Nabble.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. > > -- 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.
