Is there any reason not to use same argument names in database fields
and form fields? I have been playing with newforms and I constantly
write "max_length" argument in CharField as "maxlength" which is used
in database and oldforms CharField.
Jani
--~--~-~--~~~---~-
On 11/16/06, gabor <[EMAIL PROTECTED]> wrote:
> - what is the plan, how should incoming data (GET or POST) handled?
> some possibilities:
> [...]
> - we assume it's DEFAULT_CHARSET. we do not failover (means that if that
> data is not in DEFAULT_CHARSET, the newforms code will (because of
> "unico
On 11/16/06, SmileyChris <[EMAIL PROTECTED]> wrote:
> It would be nice to have a verbose_name option for fields in newforms
> for when you want an alternate to the magical pretty_name. I've been
> trying to think about where best to put a it.
>
> The end goal is that BoundFields have verbose_name
On 11/16/06, SmileyChris <[EMAIL PROTECTED]> wrote:
> It seems like a great opportunity as newforms develops to clean up the
> database fields mess. Most of the arguments you pass a database field
> are not related to the database.
>
> Is this part of the goal of newforms, or am I thinking too big
Hello,
This is what came to my mind a second ago (maybe two) after reading
James Bennett's blog entry 'Django tips: get the most out of generic
views'[0].
Wouldn't it be nice to have generic views (REST APIs) for:
- Filesystem operations (on *nix for a start). Loose coupling with
Python's OS mo
Hi Jeroen,
Sorry about the closed blog comments, that entry was getting dozens of
spam comments per day even though we use MT-Blacklist.
Anyway, your idea seems sound; I'd have to make or see an example
implementation and try it out to know if it's the best way to go.
Given the current state of
Right, I already figured out the "runtests.py" suite, what I'm looking
for now is running all the doctests (such as those in
django/utils/text.py's get_valid_filename, get_text_list, smart_split -
and many other of django's source files)
--~--~-~--~~~---~--~~
You
Waylan Limberg wrote:
> On 11/16/06, Gary Wilson <[EMAIL PROTECTED]> wrote:
> > I did realize an example where the title filter's implementation would
> > be desired. When you've got a possessive noun:
> >
> > >>> Template("{{ text|title }}").render(Context({"text": "the boy's blob"}))
> > "The B
Hi Rob,
Below are instructions for Windows (replace the items in square
brackets). If you're using *nix, I'm sure you can figure out the
equivalent ;)
set DJANGO_SETTINGS_MODULE=[projectname].settings
set PYTHONPATH=[django_projects_folder]
python runtests.py
On Nov 17, 1:33 pm, "Rob Hudson" <[
I was just playing with trying to run the tests this morning as well.
Doing "python runtests.py" in the django/tests directory gives me an
error about the DJANGO_SETTINGS_MODULE. I couldn't figure out what
needed to be in my environment setting to get the tests to work.
Searching Google didn't t
Aidas Bendoraitis wrote:
> Not a bad change, but much more important, in my opinion, would be to
> have an ability to set the fields of inline edited models according
> the formatting set in fields list/tuple; with all the features as
> collapsible groups of fields, placing fields next to each oth
It seems like a great opportunity as newforms develops to clean up the
database fields mess. Most of the arguments you pass a database field
are not related to the database.
Is this part of the goal of newforms, or am I thinking too big?
With newforms, we can just have one optional argument (for
It would be nice to have a verbose_name option for fields in newforms
for when you want an alternate to the magical pretty_name. I've been
trying to think about where best to put a it.
The end goal is that BoundFields have verbose_name property which can
return the verbose name or fall back to th
wiswaud wrote:
> sorry to butt in, but it's quite interesting to me too...
>
> [EMAIL PROTECTED] a écrit :
>
> > If I understand what you want to do, the quick answer is that you can't
> > do it. Even at the level of mod_python, sending back a response before
> > all data has been read is unlikel
On 11/16/06, Gary Wilson <[EMAIL PROTECTED]> wrote:
>
> Gary Wilson wrote:
> > So why the special cases? Should we keep the filters consistent with
> > their str methods?
> > title -> str.title()
>
> I did realize an example where the title filter's implementation would
> be desired. When you've
Hello,
Is there a handy one-liner to run all the doctests in django? (I
checked out the trunk, have already run the unit tests with
"runtests.py" in the root "tests" directory, getting all the modeltests
and regressiontests. Looking to execute the rest of the tests before I
start hacking around!)
On 14 nov, 20:21, "Jean-Luc" <[EMAIL PROTECTED]> wrote:
> James Bennett a écrit :
>
> > On 11/14/06, James Bennett <[EMAIL PROTECTED]> wrote:
> > > IIRC I'm the one who made it do that, and it was because, at the time,
> > > the way Django handled the 'range' lookup was *not* inclusive, so it
>
Managed to post it: ticket #3029
http://code.djangoproject.com/ticket/3029/
On Nov 16, 9:26 pm, "Tim Goh" <[EMAIL PROTECTED]> wrote:
> Akismet thinks my ticket is spam -- please add me to the whitelist so
> that I can submit the following ticket and patch:
--~--~-~--~~~
Akismet thinks my ticket is spam -- please add me to the whitelist so
that I can submit the following ticket and patch:
Problem:
The date_joined and last_login fields in the contrib.auth package are
both declared as "default=models.LazyDate()", which results in the
following incorrect behavior:
sorry to butt in, but it's quite interesting to me too...
[EMAIL PROTECTED] a écrit :
> If I understand what you want to do, the quick answer is that you can't
> do it. Even at the level of mod_python, sending back a response before
> all data has been read is unlikely to prevent the client from
Am 16.11.2006 um 11:30 schrieb Aidas Bendoraitis:
>
> Not a bad change, but much more important, in my opinion, would be to
> have an ability to set the fields of inline edited models according
> the formatting set in fields list/tuple; with all the features as
> collapsible groups of fields, pl
Not a bad change, but much more important, in my opinion, would be to
have an ability to set the fields of inline edited models according
the formatting set in fields list/tuple; with all the features as
collapsible groups of fields, placing fields next to each other
horizontally, setting HORIZONT
hi,
i think it would be a good idea, to define what the "unicode policy" of
newforms should be.
i got the idea after seeing changeset 4076
i understand that this is still work-in-progress, but we still should
clearly define how we handle incoming data.
so, some question:
- what is the p
23 matches
Mail list logo
