On Mar 11, 4:52 am, "Jeroen van Dongen" <[EMAIL PROTECTED]> wrote:
> Jeff: the case in snippet 82 is covered with the FormList idea.
> However, the case as presented in snippet 27 is not. And I'm in doubt
> it's something that requires a special form class actually.
I don't think I was arguing
On Mar 10, 6:47 am, "Jeroen van Dongen" <[EMAIL PROTECTED]> wrote:
> Jeff: could you elaborate a bit on what you mean with "dynamic
> fields"?
Assigning a field dynamically is what occurs
when you only know at runtime which (or how
many) fields must be displayed. This is not
simply a matter of
Jeroen,
Right now my biggest time sink with newforms is dealing with dynamic
fields (in contrast to dynamic forms). I'd like to work up some
examples and present them as possible use cases to address, if you
think dynamic fields might fall within the scope of SuperForms.
--
Jeff Bauer
Rubicon,
On Mar 7, 3:57 am, "David Larlet" <[EMAIL PROTECTED]> wrote:
> Given the fact that label is not always at the same argument place, I
> doubt that it breaks previous code because you "need" to specify
> label=
I must have been thrown off by "maybe we can reorder arguments"
in the original post.
On Mar 6, 10:43 am, "David Larlet" <[EMAIL PROTECTED]> wrote:
> I know it's easy to type label= for all newforms fields but maybe we
> can reorder arguments in newforms before 0.96? What's your opinion
> about that? Am I the only one?
-0
You'd be breaking the code of early newforms adopters for
On Mar 1, 3:12 pm, "James Bennett" <[EMAIL PROTECTED]> wrote:
> AFAIK it will be migrated eventually to being 'max_length' everywhere,
> but probably not for this release because that's a
> backwards-incompatible change.
One possibility would be to allow max_length to be
used as a maxlength
In keeping with the overall theme of testing at this
year's PyCon, it would be nice to have integrated
testing (fixtures, ticket #2333) brought to resolution.
It was great to briefly meet everyone over the past
few days in Dallas.
--
Jeff Bauer
Rubicon, Inc.
On Feb 17, 11:29 am, "Arnaud Delobelle" <[EMAIL PROTECTED]>
wrote:
> I find it useful to have the {% for %} tag syntax extended so that one
> can write:
> {% for a,b in L %} meaning the obvious thing
+1 from me, too. Nicer than the current idiom.
--
Jeff Bauer
Rubicon, Inc.
I've not been following the newforms admin branch, but I
wondered if it could be decoupled from reliance upon
TEMPLATE_STRING_IF_INVALID == ''
It's often useful to have something like 'BADDATA' assigned
to TEMPLATE_STRING_IF_INVALID during development/testing
because such text easy to scan
+1
Aside from putting choices in __init__, my other current workaround is
to use Python's property feature:
class PhysicianChoices:
def _physicians(self):
return [(e.id, e.name) for e in \
Physician.objects.order_by('lastName','firstName') if
e.active]
choices =
I've been using the newforms for the past few
days. Prior to the Django 1.0 API lock, I'd was
hoping to address one issue.
Adrian is likely to get a bunch of enhancement requests
for newforms and it's unlikely that any given feature
set will satisfy everyone. Having a basic newforms
framework
I was retrieving field/value info from a Model
object today. The docs list how to obtain the
information from a query: Blog.objects.values()
If I want to get a single dict from the query
(ignoring error checking):
blog_dict = Blog.objects.filter(pk=1).values()[:1]
However, if I already
12 matches
Mail list logo
