On 1/6/07, Mikko Ohtamaa <[EMAIL PROTECTED]> wrote:
Hi,
I noticed that newforms don't have place for field descriptions (a long
description of field usage). Also, developers might want to associate
other data with fields too.
Here is an example how I associated description now:
http://www.oht
On 1/6/07, Mikko Ohtamaa <[EMAIL PROTECTED]> wrote:
Hi fellow snaky coders,
I just started a new web project. After a short evaluation of
Turbogears, Ruby on Rails and Django, I decided to use Django for the
project - again. Though Turbogears has good AJAX & etc. stuff, the lack
of middleware c
Hi,
I noticed that newforms don't have place for field descriptions (a long
description of field usage). Also, developers might want to associate
other data with fields too.
Here is an example how I associated description now:
http://www.ohtis.net/code/uniteworld/uniteworld/register.py
But it
Hi fellow snaky coders,
I just started a new web project. After a short evaluation of
Turbogears, Ruby on Rails and Django, I decided to use Django for the
project - again. Though Turbogears has good AJAX & etc. stuff, the lack
of middleware concept being the factor which lead me back to our
bel
Tim Keating wrote:
Looks like this hasn't been touched much since SoC work got checked in.
Is there a timeline for getting it merged up into trunk?
There have been a couple patches submitted to improve Xapian support,
but for the most part it's on the backburner until I get more time (or
someo
Looks like this hasn't been touched much since SoC work got checked in.
Is there a timeline for getting it merged up into trunk?
If not, could we get a downmerge, so we can be using that branch and
still get all the juicy mainline django goodness to work with?
--~--~-~--~~-
I'm trying to convert my user registration forms to newforms and this
was my first glitch with them. My scenario is this:
user submits username + email, which are hashed and validation email is
sent to user. (Nothing is saved to db at this point.) User comes back
with the hash, which is then de-
I agree with Russ. Either way works for me & as far as throwing an
exception, I don't really care either way either. I guess I'm not
really much help am I ;)
-Chris
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Adrian> No can do -- that would couple the database layer to HTTP,
which
Adrian> wouldn't be a good thing.
James> I wonder, though, if this is a case of practicality beating
purity;
James> also, it's incredibly ugly to raise an exception that says "I
couldn't
James> find what you asked for" and
On 1/6/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
# Unbound form with dynamic initial data
f = MyForm(initial={'foo': 'initial value'})
# Bound form with dynamic initial data
f = MyForm({'foo': 'bar'}, initial={'foo': 'initial value'})
In the last case, the initial paramet
10 matches
Mail list logo
