On 1/14/07, Michael Radziej <[EMAIL PROTECTED]> wrote:
after thinking about drproject: I'd rather switch to something
full-fledged like Bugzilla (http://www.bugzilla.org/). But I guess that
is out of question. The integration of tickets with svn and all this is
really too cool, and while bugzill
http://code.djangoproject.com/ticket/3134
Bringing discussion to the list...
I would also say that all the date based generic views should have the
same behavior, but I'm not sure if that should be making all the date
based views take an order_by parameter, or to just make archive_year
act like
Hi Andrew,
thanks for the information, I have added it to
http://code.djangoproject.com/wiki/VersionOneFeatures. And I'm convinced
it should be considered!
Michael
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "
Hi,
after thinking about drproject: I'd rather switch to something
full-fledged like Bugzilla (http://www.bugzilla.org/). But I guess that
is out of question. The integration of tickets with svn and all this is
really too cool, and while bugzilla provides a much better ticketing
system than trac
Hi Tim,
Tim schrieb:
I wonder if any of you have seen "Dr. Project". It's basically some
additional functionality built on top of Trac (includes a tag cloud and
multi-project support).
https://www.drproject.org/
Hmm, browsing through the docs the only stuff that tries to explain the
differe
Patch attached with documentation fixes, requesting review.
http://code.djangoproject.com/ticket/685
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to
On Dec 24 2006, 9:35 pm, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
On 12/24/06 4:50 PM, Gary Wilson wrote:
>> I have created a ticket for this too and have attached some code:
>>http://code.djangoproject.com/ticket/3182
> Documentation and tests attached too now.Hm - I get a whole bunch of
Granted, Jan, but a human still had to sign up their spam bot.
In the case of the web site, all the email addresses publicly
accessible to any and every spam-spider. It's just not good etiquette.
--~--~-~--~~~---~--~~
You received this message because you are su
Hi Adrian,
I noticed from the wiki on the NewformsAdminBranch that you are
considering taking this "opportunity to add extra customization hooks
to the admin site". One hook that I would like to see added is the
ability to control the field grouping (and line breaks) for related
objects. The
On 1/15/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
My proposal is a database data dumper based on django ORM - It would
not produce SQL but python code that would insert the data. Something
like (example dump):
###
from os import environ
environ['DJANGO_SETTINGS_MODULE'] =
My proposal is a database data dumper based on django ORM - It would
not produce SQL but python code that would insert the data. Something
like (example dump):
###
from os import environ
environ['DJANGO_SETTINGS_MODULE'] = 'settings'
from django.contrib.auth.models import User, G
On 1/14/07, telenieko <[EMAIL PROTECTED]> wrote:
Already saw the change on Trac, but as I said there, shouldn't
"form_for_model" set this widget automagically for File and Image Fields ?
that would be nice ;)
Hi Marc,
Yes, FileFields are one of the many things that form_for_model() does
not y
Hi Adrian,
Already saw the change on Trac, but as I said there, shouldn't
"form_for_model" set this widget automagically for File and Image Fields ?
that would be nice ;)
Cheers,
Marc.
On 1/13/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
On 1/11/07, Sergey Kirillov <[EMAIL PROTECTED]> wrote
Op zondag 14-01-2007 om 12:40 uur [tijdzone -0800], schreef SmileyChris:
It has always frustrated me that email addresses are just given away
to spammers. Is there anything that can be done to hide or obscure
commenter/submitter emails and "CC" emails?
By mailing this list, you have just sent
FYI, this is being talked about too:
http://trac.edgewall.org/ticket/153
http://trac.edgewall.org/ticket/1459
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send e
For what it's worth, I think getting this minor wart fixed would be
very helpful. I know I spent a lot of time playing around with
FloatField and decimals. I think anyt kind of app that does anything
more than basic integer math is going to stumble with these confusing
field definitions. Since
I wonder if any of you have seen "Dr. Project". It's basically some
additional functionality built on top of Trac (includes a tag cloud and
multi-project support).
https://www.drproject.org/
This may be a source of inspiration or even a solution.
--~--~-~--~~~---~-
On 1/14/07, Rob Hudson <[EMAIL PROTECTED]> wrote:
PS: This could also be used as an example of how to build an installer
for your app to send to someone for reviews. Something we're going to
need where I work in the not so distant future.
I don't like the idea of promoting installation of dja
Hi,
I would like to help with this one...
I have already written the custom widget override (ticket #3292),
which is reflected in form_for_model
I also think it might be useful to implement a page for individual app
/admin/app/
which would serve as some sort of portal for the given app (I have no
Michael Radziej wrote:
a) Would this introduce an incompatible change of an API?
Yes: models.FloatField would always return floats (not Decimals), and
introspection of DECIMAL columns would yield DecimalFields (not
FloatField). The parameters to FloatField would also change (no
precision, et
PS: This could also be used as an example of how to build an installer
for your app to send to someone for reviews. Something we're going to
need where I work in the not so distant future.
--~--~-~--~~~---~--~~
You received this message because you are subscribe
There are really at least two distinct audiences for an installer:
experienced python users who will likely have a database and python
version installed along with various add ons, and new python users who
may be thinking about moving from LAMP (where the P is PHP) to either
Ruby on Rails or hop
It has always frustrated me that email addresses are just given away to
spammers. Is there anything that can be done to hide or obscure
commenter/submitter emails and "CC" emails?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the G
On 1/14/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
I've created a newforms-admin branch, which will focus on integrating
django.newforms with the Django admin site.
I've written up some thoughts and goals for this branch:
http://code.djangoproject.com/wiki/NewformsAdminBranch
Adrian
Could admin also recieve a piece of functionality to have multiple search
forms in it ?
Very often one wants to search by name, id, smth else. Such a common piece
could be really helpful.
Hi all,
I've created a newforms-admin branch, which will focus on integrating
django.newforms with t
Hi all,
I've created a newforms-admin branch, which will focus on integrating
django.newforms with the Django admin site. A branch is necessary here
because it's a big change that will span multiple changesets and
undoubtedly cause temporary breakage.
I considered just making a separate URLconf
Hi Andrew,
Andrew Durdin wrote:
There are two open tickets regarding decimals vs floats: #200 and
#2365.
The current situation is untenable for anyone with a need for genuine
fixed-point decimal values, as there are too many cases (i.e. at least
one :-) where they might be converted to floats,
There are two open tickets regarding decimals vs floats: #200 and
#2365.
The current situation is untenable for anyone with a need for genuine
fixed-point decimal values, as there are too many cases (i.e. at least
one :-) where they might be converted to floats, with a loss of
accuracy. To summa
I think that a possible fix to this problem and to the presentation
problem (as_p, as_li, as_whichever_you_like) have been discussed in
this list (or in user list, i don't remember), and is the use of
templates instead of handcode the (X)HTML code in source.
Each widget and form could have a tem
Hi,
Michael Radziej wrote:
First, Malcolm has brought up the idea about using Trac's keywords. I've
looked up the URL from his email, and I'd like these keywords:
Oops: it wasn't brought up by Malcolm but by Gary. Sorry about that!
Michael
--~--~-~--~~~---~--~--
hi,
what is the status/future of validation-aware models? is it planned to
have them in django-1.0? last year there was some activity regarding
them, so the models do have a validate() method, but it does not seem to
be complete.
if they are not planned for django-1.0:
is there a way to va
Hi,
here are a few further suggestions for the ticket workflow.
First, Malcolm has brought up the idea about using Trac's keywords. I've
looked up the URL from his email, and I'd like these keywords:
From adrian:
- design-q (or rather: "needs-design-decision")
- ok-needs-patch (or rather: n
Malcolm Tredinnick wrote:
[...]
This seems like a reasonable idea, although I'm not sure if __repr__ is
the right place for it or not (and that's something that doesn't
interfere with the implementation anyway, so I'm not going to worry
much).
In principle __repr__ should be the right place (a
Hi Bj�rn,
This didn't seem to get a response, but it deserves some
acknowledgement...
On Fri, 2006-12-29 at 04:17 +, Bj�rn Stabell wrote:
Hi,
I would like to be able to serialize QuerySets for use as "canned"
queries etc, and looking at QuerySet it's currently delegating __repr__
to its d
34 matches
Mail list logo
