I should add that #10909 is another ticket that ultimately revolves
around getting a Site/RequestSite object to have access to the current
domain. Easily fixed once this function/method exists.
While I'm at it, #10944 would be moved one step closer by having a
consistent way to get the current Sit
Hi Tyrion,
Multicomplete have no add item button with popup.
This is usually the hardest thing to implement with such control,
because it's rendered *after* the control.
Was it that hard to subclass widgets as Admin*AutocompleteWidget and
add required css media from jquery.ui to them?
Lots of ot
Hi Gabriel, everyone,
I'd also like if such function can support option "developer provides
function that knows the current site based on the request".
That means, "get my site" function ultimately needs a backend connector!
I think this might be fixed in the way we did with urlconf:
http://docs.
On 1 October 2010 07:26, Russell Keith-Magee wrote:
> I already have one specific piece of API feedback: the current
> implementation requires that all view logic is contained in GET(),
> POST() etc style views. This is fine, except for the fact that there
> are occasions where GET and POST share
On Fri, 2010-10-01 at 11:12 +0200, Hanne Moa wrote:
> On 1 October 2010 07:26, Russell Keith-Magee wrote:
> > I already have one specific piece of API feedback: the current
> > implementation requires that all view logic is contained in GET(),
> > POST() etc style views. This is fine, except for t
Russell Keith-Magee a écrit :
I've just added a summary of the last thread on class-based views [1].
This summary isn't 100% complete -- any contributions from interested
parties are welcome. Try to keep opinions to a minimum; this page is
about documenting the strengths and weaknesses of variou
Hi Russell,
Few more questions I haven't seen answers yet.
How should urls() work for such views? Should they?
How can self.redirect_to() get current app, namespace and function
name to work if one should use reverse() ?
How should request should be passed for self.render()? Implicitly or explici
On Thu, 2010-09-30 at 23:48 -0700, Gabriel Hurley wrote:
> I went to triage a few tickets tonight, and noticed that #8960,
> #10235, #10608 and #13814 have all arrived at essentially the same
> conclusion: there needs to be a single idiomatic way to get either the
> current Site object if contrib.s
On 01/10/10 11:17, Luke Plant wrote:
Passing things around between '_common' and GET and POST makes a simple
view much more complex than it needs to be, especially when you have
various local variables that you now have to assign in some way. In the
end you will end up just routing it all to the
Hi everyone,
Anyway, I'd like to see notes from core devs regarding adding such
feature to Admin interface (so please don't say -1 if you think it's
just not mature enough!).
Or maybe all interested parties should work on some kind of
django-admin-extensions instead of improving admin itself.
Ac
Am 01.10.2010 um 07:26 schrieb Russell Keith-Magee:
> I've just added a summary of the last thread on class-based views [1].
> This summary isn't 100% complete -- any contributions from interested
> parties are welcome. Try to keep opinions to a minimum; this page is
> about documenting the strengt
I don't think we should worry about documentation nightmares - we could leave
most of it undocumented and just expose the bits which look like the current
generic views (and a few base views) as the public API.
I have added a "how to help" section to the wiki page:
http://code.djangoproject.com
On Oct 1, 3:45 am, Kevin Howerton wrote:
> Regarding the 'version' setting.. .is that in the python 2.7
> implementation? I ended up removing it from the included
> logging-config in lumberjack as it wasn't really doing much.
Yes, it's required so that we can introduce schema changes in future
P
On Sep 28, 3:07 am, Thomas Wanschik wrote:
> On 28 Sep., 02:45, Russell Keith-Magee
> wrote:
> We've started a supported/unsupported feature list on
> djangopackages:http://www.djangopackages.com/grids/g/cloud/
>
> So please help in order to get closer at least one step towards NoSQL
> in Django
On Oct 1, 11:16 am, Johannes Dollinger
wrote:
> Could you (or anyone knowledgable) add a section, that explains why each
> request should have its own view instance?
> The thread-safety argument alone does not suffice: if all _request_ state
> would be stored on request instead of the view, you
On Fri, Oct 1, 2010 at 9:53 AM, Vinay Sajip wrote:
> On Oct 1, 11:16 am, Johannes Dollinger
> wrote:
>> Could you (or anyone knowledgable) add a section, that explains why each
>> request should have its own view instance?
>> The thread-safety argument alone does not suffice: if all _request_ st
Hi.
I just filed a feature request on the same or similar issue, and this
thread was brought to my attention:
http://code.djangoproject.com/ticket/14347
Basically the usecase is this:
Very often we have a "Published" field on our models (or "Published
date" or "Published status" etc..) It would be
On Fri, Oct 1, 2010 at 6:46 PM, burc...@gmail.com wrote:
> Hi Russell,
>
> Few more questions I haven't seen answers yet.
>
> How should urls() work for such views? Should they?
Erm... no. A view doesn't have a collection of URLs. A view is a view.
What we're debating here is a way to construct g
On Fri, Oct 1, 2010 at 6:42 PM, David Larlet wrote:
>
> Russell Keith-Magee a écrit :
>
>> * Conversion of the github project into a patch on trunk.
>
> Do you see that as a total replacement of actual views.generic or should we
> go for a old/new dance?
Unless you're proposing to maintain backw
On Fri, Oct 1, 2010 at 6:17 PM, Luke Plant wrote:
> On Fri, 2010-10-01 at 11:12 +0200, Hanne Moa wrote:
>> On 1 October 2010 07:26, Russell Keith-Magee wrote:
>> > I already have one specific piece of API feedback: the current
>> > implementation requires that all view logic is contained in GET()
On Fri, Oct 1, 2010 at 9:55 AM, Alex Gaynor wrote:
> On Fri, Oct 1, 2010 at 9:53 AM, Vinay Sajip
> wrote:
> > It seems better to stress thread-safety dos and don'ts in the
> > documentation.
>
> Without wanting to beat a dead horse, I concur. Fundamentally we need
> to have a little faith in yo
On Fri, Oct 1, 2010 at 6:16 PM, Johannes Dollinger
wrote:
> Am 01.10.2010 um 07:26 schrieb Russell Keith-Magee:
>> I've just added a summary of the last thread on class-based views [1].
>> This summary isn't 100% complete -- any contributions from interested
>> parties are welcome. Try to keep opi
I know I'm not a core dev but I do have two cents.
I'm not really in favor of overthinking this too much--I think a
satisfactory replacement for raw_id_fields is good enough (adequately
encompasses all the features). I know there are a lot of mature
projects out there when it comes to AjaxFields a
On Fri, Oct 1, 2010 at 11:16 AM, Russell Keith-Magee
wrote:
> On Fri, Oct 1, 2010 at 6:16 PM, Johannes Dollinger
> wrote:
>> Am 01.10.2010 um 07:26 schrieb Russell Keith-Magee:
>>> I've just added a summary of the last thread on class-based views [1].
>>> This summary isn't 100% complete -- any c
Edit. Edit.
"I just don't think making an absolute answer to that discussion a
contingency to this called-for feature /is a good idea/".
There we go.
On Oct 1, 11:19 am, "subs...@gmail.com" wrote:
> Please don't think I'm trying to hinder discussion. I just don't think
> making an absolute answ
On Oct 1, 2010, at 10:20 AM, Alex Gaynor wrote:
> Not really. The big win from a class-based view is not being able to
> store state, you can do that with local variables, it's being able to
> override parts of the behavior without needing to rewrite the entire
> view, or add 101 parameters.
If
On Fri, Oct 1, 2010 at 11:20 PM, Alex Gaynor wrote:
> On Fri, Oct 1, 2010 at 11:16 AM, Russell Keith-Magee
> wrote:
>> On Fri, Oct 1, 2010 at 6:16 PM, Johannes Dollinger
>> wrote:
>>> Am 01.10.2010 um 07:26 schrieb Russell Keith-Magee:
I've just added a summary of the last thread on class-b
On 01/10/10 16:25, Brandon Konkle wrote:
On Oct 1, 2010, at 10:20 AM, Alex Gaynor wrote:
Not really. The big win from a class-based view is not being able to
store state, you can do that with local variables, it's being able to
override parts of the behavior without needing to rewrite the
On Fri, Oct 1, 2010 at 1:44 AM, Tai Lee wrote:
> I'd like to suggest (1) easy to find and use pre-defined searches to
> find tickets at each stage of triage, (2) a clearer indication of the
> next steps and the person responsible for it whenever a ticket is
> reviewed, and (3) tickets that have be
I feel like something like this would be better suited to be in an
external application... since it will fail without a cache-backend.
Also, the implementation will have to change as Russell is about to
commit a logging patch with ticket #12012.
This would be best suited though for a custom handl
On Fri, 2010-10-01 at 12:16 +0200, Johannes Dollinger wrote:
> Am 01.10.2010 um 07:26 schrieb Russell Keith-Magee:
> > I've just added a summary of the last thread on class-based views
> [1].
> > This summary isn't 100% complete -- any contributions from
> interested
> > parties are welcome. Try to
>
> We document the issue, warn people not to store state on the instance
> itself, but tell them that if they must have stateful data, it should be
> attached to self.state instead of self, and they will be OK. They might
> still be bitten if they put mutable configuration data into the __init__
Or, more drastically, we could just do this:
class View(object):
def __call__(self, request, *args, **kwargs):
self.request = request
self.args = args
self.kwargs = kwargs
resp = self.dispatch(request, *args, **kwargs)
self.__dict__ = {} # goodbye state!
> This would kill the ability to use __init__ to store anything on the
> instance, since it would only work for the first request, and so would
> enforce subclassing as the only means of customising behaviour. It would
> be more effective at dealing with thread safety concerns than a
> 'copy()', bu
I see a huge list of tickets that shoud be in 1.3 release:
http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&milestone=1.3
Within them I didn't found some that are, imho, a must for every
Django installation I did in the last two years:
Better raw_id_fields feedback i
Am 01.10.2010 um 18:07 schrieb Luke Plant:
> On Fri, 2010-10-01 at 12:16 +0200, Johannes Dollinger wrote:
>> Am 01.10.2010 um 07:26 schrieb Russell Keith-Magee:
>>> I've just added a summary of the last thread on class-based views
>> [1].
>>> This summary isn't 100% complete -- any contributions
Form wizard docs mention that MD5 hashes are made using
settings.SECRET_KEY -
http://docs.djangoproject.com/en/dev/ref/contrib/formtools/form-wizard/#django.contrib.formtools.wizard.FormWizard.security_hash
If you give me a value, I give you a hash back, and you're aware that
I'm using Django (thi
On Oct 1, 4:16 pm, Russell Keith-Magee
wrote:
> "Don't use instance variables on a class" isn't advice you're going to
> see printed very often. Yet that would be the advice that would be
> *required* in order to use stateless class-based views in the way you
> describe.
>
> Objects have state.
Well, looking at those two tickets, #7028 is currently related to the
debate happening on this list ("rethinking raw_id_fields"), so the
best thing to do for that ticket is to actively participate in that
discussion.
For #6903 the ticket is in DDN, which means this is a perfect
opportunity for the
On Fri, Oct 1, 2010 at 1:41 PM, Gabriel Hurley wrote:
...
> In both cases, once that's done you can either write/help write a
> patch that has the desired effect, make sure it has docs and tests,
> test it on your own systems/projects, give feedback on the ticket...
> if you're certain it meets al
Sorry, that was phrased badly on my part. I meant to imply that if
someone else wrote a patch, he could help by reviewing it...
- Gabriel
On Oct 1, 11:47 am, Jeremy Dunck wrote:
> On Fri, Oct 1, 2010 at 1:41 PM, Gabriel Hurley wrote:
>
> ...
>
> > In both cases, once that's done you can eit
I can see why you might want control at the middleware level, but I'm
not sure that's the only/best way to accomplish that goal, and it
seems like the subject of a totally separate ticket to me. I'd rather
see this set of redundant problems solved in a simple fashion rather
than get into a debate o
Hi All!
After installing django and creating a project runing "django-admin.py
startproject", if I setup a sqlite3 database and try to run the tests
(python manage.py test) it will fail.
Seems that contrib.auth tests are missing 2 template files, making it
dependent of contrib.admin templates, ho
Hey...
Discussed with Russell on IRC ... line 21 of log.py...
# Ensure the creation of the Django logger
logger = logging.getLogger('django')
I guess it's trying to check if the logger exists? The getLogger
method will actually never fail (as far as I'm aware), as nothing
actually happens until
Hello everyone!
During a sprint before 1.2 I was proposing to commit my ticket [9886]
that deals with adding a .read() method to HttpRequest. Adrian suggested
that it was too late then and it's better to bring it up during 1.3
cycle. So here it is.
Basic summary of changes is in the first co
On Fri, Oct 1, 2010 at 4:46 PM, Ivan Sagalaev
wrote:
> During a sprint before 1.2 I was proposing to commit my ticket [9886] that
> deals with adding a .read() method to HttpRequest. Adrian suggested that it
> was too late then and it's better to bring it up during 1.3 cycle. So here
> it is.
Loo
My problem with all of this is that it feels like a hell of a lot of
hoopjumping to deal with something that could be solved in the
Resolver.
I may be missing something obvious here, so please tell me if I am..
but couldn't the resolver just check that quacks like something
OOViewish has been pass
Sorry in my previous email you could simply pass the uninstantiated
class in the url pattern.
url(r'...',MyOOView,...)
On Sat, Oct 2, 2010 at 8:57 AM, David P. Novakovic
wrote:
> My problem with all of this is that it feels like a hell of a lot of
> hoopjumping to deal with something that could
On Fri, 2010-10-01 at 12:08 -0700, Gabriel Hurley wrote:
> I can see why you might want control at the middleware level, but I'm
> not sure that's the only/best way to accomplish that goal, and it
> seems like the subject of a totally separate ticket to me. I'd rather
> see this set of redundant pr
On Oct 1, 10:28 pm, Kevin Howerton wrote:
> # Ensure the creation of the Django logger
> logger = logging.getLogger('django')
>
I think the comment is misleading. I agree, there'd be no need to
create the logger there as it doesn't seem to be used there. Two
points:
1. Library code should add
On Fri, 2010-10-01 at 10:59 -0700, Yo-Yo Ma wrote:
> Form wizard docs mention that MD5 hashes are made using
> settings.SECRET_KEY -
> http://docs.djangoproject.com/en/dev/ref/contrib/formtools/form-wizard/#django.contrib.formtools.wizard.FormWizard.security_hash
>
> If you give me a value, I give
On Oct 1, 7:06 am, Russell Keith-Magee
wrote:
>
> These are fairly minor modifications, so I'm still intending to commit
> early next week, barring major objections.
>
As per my answer to Kevin - I think a NullHandler addition to the
'django' logger needs to happen internally (not under a site
Definitely agree. Caught the missing nullhandler behavior when
logging is off too... though didn't make the connection that this was
likely intended to handle that case.
It might make more sense to put this logic in conf/__init__.py
following the calls to configure the logger. Though that doesn'
On Saturday, October 2, 2010, David P. Novakovic
wrote:
> My problem with all of this is that it feels like a hell of a lot of
> hoopjumping to deal with something that could be solved in the
> Resolver.
>
> I may be missing something obvious here, so please tell me if I am..
> but couldn't the re
Yeah, I actually read your modification of the trac page after posting this :\
I guess what I'm getting at is the more general issue of maintaining
the same interface... is it really that important?
If people acknowledge that they are using a different system, then
they can adjust their expectati
On Saturday, October 2, 2010, Vinay Sajip wrote:
>
> On Oct 1, 4:16 pm, Russell Keith-Magee
> wrote:
>
>> "Don't use instance variables on a class" isn't advice you're going to
>> see printed very often. Yet that would be the advice that would be
>> *required* in order to use stateless class-base
On Sat, Oct 2, 2010 at 12:20 AM, Alex Gaynor wrote:
> Not really. The big win from a class-based view is not being able to
> store state, you can do that with local variables, it's being able to
> override parts of the behavior without needing to rewrite the entire
> view, or add 101 parameters.
On Sat, Oct 2, 2010 at 12:26 PM, Ian Lewis wrote:
> On Sat, Oct 2, 2010 at 12:20 AM, Alex Gaynor wrote:
>> Not really. The big win from a class-based view is not being able to
>> store state, you can do that with local variables, it's being able to
>> override parts of the behavior without needi
On Sat, Oct 2, 2010 at 11:37 AM, David P. Novakovic
wrote:
> By this reasoning, when you add extra helper methods to your class,
> which is the reason for OO views, you need to add/use the data those
> methods will modify to the request object? That just doesn't make
> sense to me at all. It remin
On Oct 1, 10:00 pm, Russell Keith-Magee
wrote:
> Now, I'm sure the counterargument is going to be that copy() will be
> just as error prone and FAQ inducing. My argument to this is:
Yes.
> * when it fails, it will fail during development, not just in production
>
> * the cases where it wil
60 matches
Mail list logo
