It also appears that a dashed name can cause problems in templates,
as it is interpreted as minus sign.
On 07-Jun-12, at 5:42 PM, David Priest wrote:
> Well, now, that is an interesting find.
>
> It seems to me the upcoming prefix attribute should result in a
> dotted name, not
Lordy, I would dearly *LOVE* for someone to answer your question!
On 07-Jun-5, at 6:52 AM, larry wrote:
>
>> I'm not sure what "a patch in the development tree" means here.
>> Current
>> subversion trunk doesn't seem to have anything like that.
>
> Sorry for not being clear -- I'm (obviously)
Well, now, that is an interesting find.
It seems to me the upcoming prefix attribute should result in a
dotted name, not a dashed one, so that one could make good use of
this utility.
On 07-Jun-10, at 9:35 PM, SmileyChris wrote:
> django.utils.datastructures.DotExpandedDict
--~--~
script work,
one does want the id to be unique. Right now, both attributes get
nailed, which makes them far less useful in distinguishing things 2-
dimensionally (by row and by field group).
On 07-Jun-11, at 3:21 PM, Malcolm Tredinnick wrote:
>
> On Mon, 2007-06-11 at 15:10 -0700,
underscore.) The names come out as line_1-FieldName.
It's then child's play to tell which datum belong to which
field. :) Happy, happy!
On 07-Jun-10, at 6:10 PM, David Priest wrote:
>
> request.POST returns a QueryDict object for those fields that have
> the same key. The
request.POST returns a QueryDict object for those fields that have
the same key. The key appears to be assigned by Django when it
magics the form and template into an http response.
It seems difficult to get Django to deal with multiple lines on a
form, ie. as when creating almost any busi
Templates can output any textfile we care, right? And django's got
this nifty auto-updating thing going, where changes to a file are
immediately reloaded into the running application. So...
We use forms_for_model to get the fields, put it into a request
context, and call a template which
On 07-May-21, at 5:56 PM, Malcolm Tredinnick wrote:
> It sounds like you want the django.newforms.formsets capability that
> isn't on trunk yet.
>
> A little more patience will be required.
Is this patience measured in days and short weeks, or in long weeks
turning to months? I need to decide
I believe I have performed exhaustive research on the challenge of
creating forms that incorporate fields from multiple tables. I have
not found *any* comprehensive, best-practices examples of this problem.
It really quite surprises me, as any web application of even moderate
complexity re
On 07-May-18, at 6:33 AM, Malcolm Tredinnick wrote:
>
> On Thu, 2007-05-17 at 20:08 -0700, David Priest wrote:
>> It occurs to me that were I able to write the following:
>> models_list = (
>> 'project.app1.models.Claim',
>>
After bashing at it some more, I had to conclude I was out to lunch.
It is killing me to wait for newforms. It's senseless for me to
learn old forms, but I'm having a helluva time making heads or tails
of newforms. Some things that I swear must be common as mud -- like
a form that sends t
It occurs to me that were I able to write the following:
models_list = (
'project.app1.models.Claim',
'project.app2.models.Vendor')
fields_list = (
'Claim.vendor',
'Task.title',
'Task.description',
12 matches
Mail list logo
