On Oct 2, 11:27 pm, Russell Keith-Magee
wrote:
> Hi all,
>
> I've just uploaded a second alpha of the patch introducing unittest2
> into Django's core [1]. As with last time, help is requested running
> the test suite on different Python versions and different databases.
> Particular attention is
There is now a ticket and a patch for this, which includes the utility
method and a rollup of fixes for the aforementioned tickets as
appropriate. Tests and docs included. Details are in the ticket
description:
http://code.djangoproject.com/ticket/14386
I'd love to get some feedback on it when po
Sorry I didn't reread this thread, or remembered it after my previous post.
I just replied to clearify my previous post.
Tino
On Mon, Oct 4, 2010 at 02:57, LookMa NoSQL wrote:
> Tino, are you joking? Did you even bother to read the OP's proposal. I
> think there is a real lack of patience when
Hi Gabriel,
looking good!
On Mon, Oct 4, 2010 at 2:59 PM, Gabriel Hurley wrote:
> There is now a ticket and a patch for this, which includes the utility
> method and a rollup of fixes for the aforementioned tickets as
> appropriate. Tests and docs included. Details are in the ticket
> descriptio
We're playing semantic leapfrog here, but I don't see the proposed Ajax
solution as "searching", I see it as "autocompleting"; people won't use it
to discover content, they will use it as a shortcut for accessing content
that they are familiar with. As I said, much of the utility of the
raw_id_fiel
On 4 Ott, 04:09, Chuck Harmston wrote:
> An Ajax admin solution (of the autocomplete sort, which I presume is what
> you're proposing) does not have the same use case for raw_id_fields. It's
> based on the assumption that the user knows the value of the unicode
> representation of the object. It d
On 03/10/10 03:20, Russell Keith-Magee wrote:
* Ignore the legitimate occasions where using state is a useful
architectural approach.
I'd just like to add more noise to the signal and reiterate this -
storing state on self (or request) leads to much cleaner, less fragile,
more subclassa
Righton. I haven't used it too intensely for filtering and sorting but
I do have some other thoughts about that.
1) Would it be better to come up with a non-changelist changelist for
raw_id_fields. I find myself avoiding raw_id_fields because I don't
necessarily want to register the object in ques
On Oct 3, 8:08 pm, Russell Keith-Magee
wrote:
> On Mon, Oct 4, 2010 at 8:56 AM, Sean Brant wrote:
>
> > On Oct 3, 2010, at 7:37 PM, Russell Keith-Magee wrote:
>
> >> On Mon, Oct 4, 2010 at 4:53 AM, Sean Brant wrote:
> >>> I know this has come up over the last few years[1] and people are
> >>>
>
> On Mon, Oct 4, 2010 at 8:08 AM, Andrew Godwin wrote:
>
> I'd just like to add more noise to the signal and reiterate this - storing
> state on self (or request) leads to much cleaner, less fragile, more
> subclassable views (in my own experience, having written both a set of
> generic views w
On Oct 2, 10:32 pm, Russell Keith-Magee
wrote:
> I completely agree that we don't want to rush this. The upside is that
> if we *can* reach consensus, it isn't going to require a whole lot of
> code changes; We're arguing about how to architect the base class, but
> once we've got that sorted out
On 04/10/10 17:28, legutierr wrote:
* First, treat data processing and retrieval as separable from
rendering. Create a bright line of separation between the two
conceptual elements of the view (data and rendering), and do it early
on, at a high level, inside dispatch(). Instead of expecting
On Mon, Oct 4, 2010 at 1:04 PM, Andrew Godwin wrote:
> On 04/10/10 17:28, legutierr wrote:
>>
>> * First, treat data processing and retrieval as separable from
>> rendering. Create a bright line of separation between the two
>> conceptual elements of the view (data and rendering), and do it ear
On Mon, Oct 4, 2010 at 12:08 PM, Alex Gaynor wrote:
> Given that the primary complain against the __new__ solution is that
> it's unintuitive to Python programmers that instantiating their class
> results in some other class, why not simply go with a more explicit
> classmethod. Simply used as:
>
Thank you all for the great insights.
On Oct 3, 8:07 pm, Russell Keith-Magee
wrote:
> On Mon, Oct 4, 2010 at 10:11 AM, Laurent Luce wrote:
> > Hello,
>
> > I added the localflavor for Belgium as my first contribution. I would
> > like to contribute more code wise. I looked at the tickets with
>
On Mon, 2010-10-04 at 13:08 -0400, Alex Gaynor wrote:
> Given that the primary complain against the __new__ solution is that
> it's unintuitive to Python programmers that instantiating their class
> results in some other class, why not simply go with a more explicit
> classmethod. Simply used as:
On 4 October 2010 19:22, Jacob Kaplan-Moss wrote:
> On Mon, Oct 4, 2010 at 12:08 PM, Alex Gaynor wrote:
>> Given that the primary complain against the __new__ solution is that
>> it's unintuitive to Python programmers that instantiating their class
>> results in some other class, why not simply g
On Mon, 2010-10-04 at 19:37 +0200, Łukasz Rekucki wrote:
> The only problem is decorators: You can't just simply apply
> login_required() to the class or the dispatch() method. Otherwise, I
> like this approach.
It works fine:
http://bitbucket.org/spookylukey/django-class-views-experiments/src/
On Mon, 2010-10-04 at 13:08 -0400, Alex Gaynor wrote:
> Given that the primary complain against the __new__ solution is that
> it's unintuitive to Python programmers that instantiating their class
> results in some other class, why not simply go with a more explicit
> classmethod. Simply used as:
On 4 October 2010 19:44, Luke Plant wrote:
> On Mon, 2010-10-04 at 19:37 +0200, Łukasz Rekucki wrote:
>
>> The only problem is decorators: You can't just simply apply
>> login_required() to the class or the dispatch() method. Otherwise, I
>> like this approach.
>
> It works fine:
>
> http://bitbu
On 4 October 2010 20:03, Luke Plant wrote:
> On Mon, 2010-10-04 at 13:08 -0400, Alex Gaynor wrote:
>> Given that the primary complain against the __new__ solution is that
>> it's unintuitive to Python programmers that instantiating their class
>> results in some other class, why not simply go with
Hello,
I am looking at ticket #14268 on reset and sqlreset management
commands should raise PendingDeprecationWarning for 1.3.
I added some code to django/core/management/commands/reset.py and
django/core/management/sql.py to raise the appropriate warning.
What message should I displayed ? I hav
On Mon, 2010-10-04 at 13:08 -0400, Alex Gaynor wrote:
> Last idea, I swear,
I didn't swear, so here is another slight variation :-) You actually
*call* the classmethod in your URLconf, passing any constructor
arguments to it:
url(r'^detail/author/(?P\d+)/$',
views.AuthorDetail.as_view(so
On Oct 4, 7:22 pm, Jacob Kaplan-Moss wrote:
> On Mon, Oct 4, 2010 at 12:08 PM, Alex Gaynor wrote:
> > Given that the primary complain against the __new__ solution is that
> > it's unintuitive to Python programmers that instantiating their class
> > results in some other class, why not simply go
On Oct 4, 9:16 pm, Luke Plant wrote:
> On Mon, 2010-10-04 at 13:08 -0400, Alex Gaynor wrote:
> > Last idea, I swear,
>
> I didn't swear, so here is another slight variation :-) You actually
> *call* the classmethod in your URLconf, passing any constructor
> arguments to it:
>
> url(r'^detail/auth
On Tue, Oct 5, 2010 at 5:21 AM, George Sakkis wrote:
>
> Since dispatch is going to be defined on the base View class, can't we
> omit it from the urlconf and have the URLresolver do:
>
> if isinstance(view, type) and issubclass(view, View):
> view = view.dispatch
Russ mentioned this one ca
I agree with George, and would like to not have to write the dispatch
out every time, but my only concern is how confusing an implicit
dispatch would be for developers first using the new class-based Views
system. As long as it was made abundantly clear via the docs what
exactly is happening when y
Hello,
I added a patch to this ticket http://code.djangoproject.com/
ticket/10944">#10944
- add method get_url to Site model to return an absolute url based on
a relative path passed as an argument.
- add site_url template tag doing the same
I am not sure about the method and template tag names.
On Oct 4, 10:55 pm, "David P. Novakovic"
wrote:
> On Tue, Oct 5, 2010 at 5:21 AM, George Sakkis wrote:
>
> > Since dispatch is going to be defined on the base View class, can't we
> > omit it from the urlconf and have the URLresolver do:
>
> > if isinstance(view, type) and issubclass(view, View)
On Tuesday, 5 October 2010 at 12:17 AM, Sean Brant wrote:
On Oct 3, 8:08 pm, Russell Keith-Magee
wrote: On Mon, Oct 4, 2010 at 8:56 AM, Sean Brant
wrote: > Thanks for the feedback Russ. I know it couldn't be that straight
forward. I'll work on a p
Just throwing the idea out there, it would be possible to keep the tag
completely backwards compatible by using a slightly different syntax
for variables.
Standard non-variable access stays the same: {% url home %}, {% url
edit-profile profile.pk %}
Variable access is done via a "var=" first argu
On Tue, Oct 5, 2010 at 2:55 AM, Laurent Luce wrote:
> Hello,
>
> I am looking at ticket #14268 on reset and sqlreset management
> commands should raise PendingDeprecationWarning for 1.3.
>
> I added some code to django/core/management/commands/reset.py and
> django/core/management/sql.py to raise
I am currently using the patch provided in the ticket
http://code.djangoproject.com/ticket/13914 in my Django project. It's a
small change, but I find it to be very helpful.
Since the ticket seems to be be inactive I decided to come here and ask for
someone to review it. I am not very familiar wit
Hi Jacob,
Thanks for your feedback.
> For (1) check out http://code.djangoproject.com/wiki/Reports(it's
> linked in the nav). If there's anything missing there, please feel
> free to add it -- it's a wiki page. Let me know if you need help
> figuring out the linked query syntax.
I wasn't able to
On Tue, Oct 5, 2010 at 7:27 AM, SmileyChris wrote:
> Just throwing the idea out there, it would be possible to keep the tag
> completely backwards compatible by using a slightly different syntax
> for variables.
>
> Standard non-variable access stays the same: {% url home %}, {% url
> edit-profile
On Tue, Oct 5, 2010 at 8:16 AM, Tai Lee wrote:
> Hi Jacob,
>
> Thanks for your feedback.
>
>> For (1) check out http://code.djangoproject.com/wiki/Reports(it's
>> linked in the nav). If there's anything missing there, please feel
>> free to add it -- it's a wiki page. Let me know if you need help
Hi Russ,
On Oct 5, 11:48 am, Russell Keith-Magee
wrote:
> There have been a couple of suggestions recently that the contributing
> guide should be distilled into a specific HOWTO for new users. I
> suppose the idea here would be for the contribution guide to be the
> letter of the law, and the H
Thanks for those details. In case someone is using those commands and
is kind of happy with them, what would be the alternative? sql_reset =
sql_delete + sql_add but those commands are not exposed so I am
wondering.
Laurent
On Oct 4, 4:54 pm, Russell Keith-Magee
wrote:
> On Tue, Oct 5, 2010 at 2
On Tue, Oct 5, 2010 at 9:58 AM, Tai Lee wrote:
> Hi Russ,
>
> On Oct 5, 11:48 am, Russell Keith-Magee
> wrote:
>
>> > Perhaps we need another triage stage for these tickets, "Needs final
>> > review" or something?
>>
>> That's essentially what RFC is. This is an area where our documented
>> proce
On Tue, Oct 5, 2010 at 10:02 AM, Laurent Luce wrote:
> Thanks for those details. In case someone is using those commands and
> is kind of happy with them, what would be the alternative? sql_reset =
> sql_delete + sql_add but those commands are not exposed so I am
> wondering.
It depends a little
I added a patch for this ticket. http://code.djangoproject.com/ticket/14268
I created a new ticket to update django-admin.1 before 1.3:
http://code.djangoproject.com/ticket/14391
I will work on it next.
Laurent Luce
On Oct 4, 7:37 pm, Russell Keith-Magee
wrote:
> On Tue, Oct 5, 2010 at 10:02 AM
On Tue, Oct 5, 2010 at 5:43 AM, George Sakkis wrote:
> On Oct 4, 10:55 pm, "David P. Novakovic"
> wrote:
>> On Tue, Oct 5, 2010 at 5:21 AM, George Sakkis
>> wrote:
>>
>> > Since dispatch is going to be defined on the base View class, can't we
>> > omit it from the urlconf and have the URLresolv
On Tue, Oct 5, 2010 at 3:16 AM, Luke Plant wrote:
> On Mon, 2010-10-04 at 13:08 -0400, Alex Gaynor wrote:
>
>> Last idea, I swear,
>
> I didn't swear, so here is another slight variation :-) You actually
> *call* the classmethod in your URLconf, passing any constructor
> arguments to it:
>
> url(r
On Oct 4, 7:37 pm, Russell Keith-Magee
wrote:
> On Tue, Oct 5, 2010 at 10:02 AM, Laurent Luce wrote:
> > Thanks for those details. In case someone is using those commands and
> > is kind of happy with them, what would be the alternative? sql_reset =
> > sql_delete + sql_add but those commands a
On Tue, Oct 5, 2010 at 1:22 PM, ptone wrote:
>
>
> On Oct 4, 7:37 pm, Russell Keith-Magee
> wrote:
>> On Tue, Oct 5, 2010 at 10:02 AM, Laurent Luce
>> wrote:
>> > Thanks for those details. In case someone is using those commands and
>> > is kind of happy with them, what would be the alternative
45 matches
Mail list logo