Re: Proposal: Nice(r) error messages when a user-provided module fails to load

[Russell Keith-Magee]

On Wed, Jun 2, 2010 at 1:58 AM, Charlie Nolan  wrote:
> It was suggested in bug #13480 that I raise this issue "during the 1.3
> feature discussion phase", which we seem to have entered.
>
> Essentially, the issue is that a typo in my_app/views.py or any of its
> dependencies can raise an error on module import and break the entire
> site, leaving the user with a completely uninformative
> webserver-provided error page.  This error page is /not/ the one
> provided by Django when DEBUG is enabled in settings.py.  Effectively,
> DEBUG is locked off for this type of error.  It's also possible that
> the standard non-DEBUG error page mechanisms are bypassed as well, but
> I have not tested this.
>
> Adding either of following two lines to the start of my_app/views.py
> will trigger this behavior:
>
> import djagno # ImportError
> print print "Hello, world!" # SyntaxError.
>
> Attached to bug #13480 you will find a proof-of-concept patch that
> catches both of these errors and reroutes them to the standard (i.e.
> DEBUG-respecting) error mechanisms.  I call it a proof-of-concept
> because I took the minimum steps necessary to solve the problem as I
> experience it.  Django as a whole might be better served by a more
> comprehensive solution... or simply one written by someone who has
> enough experience with Django's internals to see the Right Way to
> handle things.  You are, of course, welcome to use the patch as
> written if you find it adequate.

There are many areas in Django's codebase where error reporting could
be improved; see [1] for a working list of some of them. If someone
wants to make a project out of addressing these issues, they certainly
have my blessing.

Regarding #13480 specifically -- I haven't dug into the problem in
detail, but the approach of telling exceptions apart by inspecting the
number of arguments doesn't fill me with joy. One of the changes in
1.2 was to improve the ability to distinguish between import errors
caused by missing modules, and import errors caused by problems with
the module being imported; I'd like to think that we are now in a
better position to report the underlying cause of ImportErrors rather
than trying to wrap them.

Also - the patch appears to be against 1.0.2; does the patch still
apply to trunk? 1.2 saw a number of changes to the view handling and
the module loading code, so it wouldn't surprise me if the patch no
longer applies.

[1] http://code.djangoproject.com/wiki/BetterErrorMessages

> As I mentioned to Arthur Koziel a few days ago, a cursory glance at
> his GSoC summary suggests that there may be some overlap between that
> and this change.  I'm not sure whether that's important to this
> proposal or not.

I'm not convinced there will be a strong overlap here. I'm sure
Arthur's code will probably overlap - after all, he is dealing with
model loading - but I don't see that what he is doing directly relates
to the errors that are raised during loading. I wouldn't be at all
surprised if his new importer just inherits whatever error handling
already exists.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Class based generic views in 1.3?

[Horst Gutmann]

On Sat, May 29, 2010 at 11:06 PM, Ben Firshman  wrote:
> Luke, you're absolutely right that changing the definition of a view is a bad 
> idea, it just seemed the best solution then.
>
> But don't worry, we've changed our minds again! If __call__() creates a copy 
> of self and calls methods on the copy, as far as I can see it solves all our 
> problems. No boilerplate, and it's really hard to make it unsafe thread-wise.
>
> An example of how it could work:
>
> http://github.com/bfirsh/django-class-based-views/blob/master/class_based_views/base.py
>
> Thanks
>
> Ben

Hi :-)

I'm not really sure about that approach. As with __new__, __call__
comes (at least for me) with a bunch of expectations. For me it
executes and operates on one single instance of an object. Sure, this
could be interpreted as using the instance as a factory for usually
you'd use class methods for something like that, but still.

On the other hand I can definitely see the merit in it since you could
then easily programmatically modify the "view" factory by just
modifying "yet another object".

-- Horst

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: exception handling memory leak...

[Kevin Howerton]

This was not a "hey you guys are lazy", actually came across it ...
after I had fixed the same issue.

I just posted a patch for you generated off trunk... and left a
hopefully somewhat entertaining explanation of the details surrounding
the issues.

-k

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Class based generic views in 1.3?

[Ben Firshman]

On 2 Jun 2010, at 22:31, Luke Plant wrote:

> On Tuesday 01 June 2010 11:43:30 henning.schroe...@gmail.com wrote:
>> On May 30, 7:24 am, Waldemar Kornewald  wrote:
>>> Maybe I missed something, but why don't you use __new__ instead
>>> of copying the instance?
>> 
>> Here is an example where I used __new__ for class based views in my
>> project:
>> http://djangosnippets.org/snippets/2046/
>> No __call__ or as_view is needed with this approach.
>> I can easily replace a function with a class without changing the
>> url configuration.
> 
> This is an interesting approach.  The only downside I can think of at 
> the moment is that implementing __new__() like that really violates 
> expectations - Python programmers have a fairly strong expectation 
> that if you do 'x = SomeClass()', where SomeClass is defined as a 
> class, then x will be an instance of SomeClass.

Yeah, this idea came up at the sprints, but it's a little too magic for my 
tastes.

Ben

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Class based generic views in 1.3?

[Luke Plant]

On Tuesday 01 June 2010 11:43:30 henning.schroe...@gmail.com wrote:
> On May 30, 7:24 am, Waldemar Kornewald  wrote:
> > Maybe I missed something, but why don't you use __new__ instead
> > of copying the instance?
> 
> Here is an example where I used __new__ for class based views in my
> project:
> http://djangosnippets.org/snippets/2046/
> No __call__ or as_view is needed with this approach.
> I can easily replace a function with a class without changing the
> url configuration.

This is an interesting approach.  The only downside I can think of at 
the moment is that implementing __new__() like that really violates 
expectations - Python programmers have a fairly strong expectation 
that if you do 'x = SomeClass()', where SomeClass is defined as a 
class, then x will be an instance of SomeClass.

Luke

-- 
"Oh, look. I appear to be lying at the bottom of a very deep, dark 
hole. That seems a familiar concept. What does it remind me of? Ah, 
I remember. Life."  (Marvin the paranoid android)

Luke Plant || http://lukeplant.me.uk/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Class based generic views in 1.3?

[Luke Plant]

On Wednesday 02 June 2010 16:08:24 Roald wrote:
> Maybe I've missed the reason, or it's just too late to change, but
> why not using a class itself (so basically its __init__ method) as
> a view. I'm using something like this in my projects (as a base
> class):
> 
> class View(HttpRequest):
> def __init__(self, request, *args, **kwargs):
> ...
> super(View, self).__init__(self.content())
> ...
> 

You mean:

 class View(HttpResponse):
 ...

One reason against this is it makes it harder to re-use other views 
from within the View.  You are forced to mutate the 'self' instance of 
HttpResponse (or else use some nasty hack), rather than being able to 
simply return the HttpResponse that might be returned from a utility 
function or a sub-view.

Luke

-- 
"Oh, look. I appear to be lying at the bottom of a very deep, dark 
hole. That seems a familiar concept. What does it remind me of? Ah, 
I remember. Life."  (Marvin the paranoid android)

Luke Plant || http://lukeplant.me.uk/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: First-class WSGI support in Django 1.3 / twod.wsgi

[Gustavo Narea]

Hello, Russell et al.

I am not saying that Django's WSGI implementation doesn't comply with
the specification. In fact, I've been talking about improving "WSGI
support" not "WSGI compliance".

It does comply with the specification, but just internally without
exposing all the WSGI-related functionality that could be consumed by
3rd party libraries. In other words, Django plays well with the
gateway using WSGI, but makes it really hard for a third component to
come into play.

I should've been more precise and have said "Open up WSGI support for
3rd party libraries", instead of simply "improve WSGI support".


On Jun 2, 4:54 pm, Russell Keith-Magee 
wrote:
> > That's right, although the proposal is not mainly to add Paste as a
> > dependency, but support WSGI middleware in a transparent way; for
> > example, the way Paste Deploy does.
>
> The issue I'm unclear on is what you mean by "transparent". Django
> provides an interface that implements the WSGI spec. There may well be
> errors in that implementation or violations of the spec, and if there
> are, I'm happy to address them. But ultimately, we either implement
> the spec or we don't.
>
> If Django's implementation of the WSGI spec is compliant, but you
> can't use it with out WSGI components, then to my reading either the
> other components aren't implementing the spec, or the WSGI spec is
> missing something big.

By "transparent" I mean that you can wrap Django with WSGI middleware
and the resulting callable would be the final WSGI application that
should be taken by the development and deployment gateway (for
example, `manage runserver' and mod_wsgi, respectively).

This callable could be the same in both scenarios, unless the
developer explicitly changes it.


> > The reason why I proposed Paste is because it's widely used and it'd
> > prevent us from implementing something that is already implemented.
>
> Your argument also presupposes that Paste is an inherently better
> implementation. Well, I don't wan't to brag, but Django also has an
> implemented WSGI implementation, and it's just as battle hardened as
> Paste. :-)
>
> I won't argue that duplication of code and effort is a virtue. If
> there is a benefit to be gained in leveraging someone else's work, and
> we can do so without compromising our own project, then we should.
> However, this raises the much larger issue of how to manage Django's
> relationship with external libraries in a way that maintains our
> 'beginner friendly' history. The 'minimal dependency' philosophy is,
> in my opinion, one of the reasons that Django has been able to get the
> traction that it has gained.

If the changes I'm proposing are accepted, not only we'd keep
backwards compatibility, but also all the documentation written so far
will still be relevant.

We wouldn't be changing existing behavior, but adding new
functionality for "advanced" users. Things would only change for those
of us who write framework-independent WSGI libraries and Django users
who want to integrate such libraries.


> There have been some initial discussions about this general problem --
> specifically, in relation to introducing support for unittest2.
> However, it's a discussion that is much larger than improving WSGI
> support, and it's a discussion that we need to have as a community.

I agree with that.


> > There are lots of WSGI middleware out there that you may want/need to
> > use, and there are even projects like Paste or Repoze whose only goal
> > is to develop framework-independent WSGI libraries (many if not most
> > of them are middleware). In the following links you can find some of
> > the WSGI middleware available and find that most of them are
> > applicable to both development and deployment:
> >http://pythonpaste.org/modindex.html(some items aren't middleware,
> > but WSGI applications)
> >http://repoze.org/repoze_components.html#middleware
> >http://wsgi.org/wsgi/Middleware_and_Utilities
>
> > Some of them are alternatives to components offered by Django itself,
> > which some people might prefer to use. Others are just things that
> > cannot/shouldn't be done at the framework level.
>
> > I'll give you one real-world example:
>
> > We don't put all the static files under MEDIA_ROOT for the limitations
> > described on  > browse_thread/thread/b333c14f40acd22a>. We have four kind of static
> > files and we want them to be in different directories:
>
> >  - Front-end files, like JS or CSS.
> >  - Files generated by our application, like thumbnails.
> >  - Uploaded files.
> >  - Uploaded files whose downloads are restricted.
>
> This is a great example of a use case where you shouldn't be using
> Django's development server at all. You have a bunch of serving rules
> for static content. A proper web server can handle those. But as far
> as developing and testing your Django application is concerned, it
> shouldn't matter how the static files 

Re: Ticket #10284

[Gabriel Hurley]

Hi, J. Alheid,

Don't be too afraid to get started. From looking at the history on
that ticket (as well as the current codebase), my guess is that
Jacob's concern is that there's no mechanism in place for handling
what happens to those objects if commit=False. The current patch tells
us what *not* to do with those objects, but doesn't do something else
with them instead. Obviously it's not good to go ahead and delete
anyway if commit is not True, but just bypassing that obj.delete()
call would raise a completely different problem.

The best way to see if that concern is valid is to write the necessary
regression test for the patch. It should verify that under the current
trunk the objects are deleted when they should *not* be, and that with
the patch applied, the objects are not only not deleted on the first
pass when commit=False, but that they are subsequently deleted when
they should be later on.

Offhand, I think I agree with Jacob that the existing patch will cause
problems on the latter part of that test case. I'm sure he knows
better than I, though.

Anyhow, that's what it needs. Oh, and btw, the chunk of code has moved
in the current trunk. The delete call is now at:

http://code.djangoproject.com/browser/django/trunk/django/forms/models.py#L604

So the patch itself needs updating regardless.

All the best,

- Gabriel

On Jun 2, 12:49 pm, Shakefu  wrote:
> Hi, I'd really like to get this ticket resolved, and I'm willing to do
> the work personally, but I've never contributed before, so I was
> hoping to solicit some guidance.
>
> It seems to me that we'd need a similar patch to the one already
> existing but updated against trunk and a patch for the documentation
> to note the change in behavior. I commented last night (Wedg) and
> someone set the needs tests flag, but I'm not entirely sure what tests
> would be needed, except maybe to validate that commit=False doesn't
> delete instances, and commit=True does.
>
> I dunno if I'm a bit too green with the contributing to take ownership
> of this ticket, but I'd like to do anything I can to help get this
> ticket's suggested behavior into trunk, for my own selfish reasons. :D
>
> Please advise,
> J. Alheid

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Ticket #10284

[Shakefu]

Hi, I'd really like to get this ticket resolved, and I'm willing to do
the work personally, but I've never contributed before, so I was
hoping to solicit some guidance.

It seems to me that we'd need a similar patch to the one already
existing but updated against trunk and a patch for the documentation
to note the change in behavior. I commented last night (Wedg) and
someone set the needs tests flag, but I'm not entirely sure what tests
would be needed, except maybe to validate that commit=False doesn't
delete instances, and commit=True does.

I dunno if I'm a bit too green with the contributing to take ownership
of this ticket, but I'd like to do anything I can to help get this
ticket's suggested behavior into trunk, for my own selfish reasons. :D

Please advise,
J. Alheid

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Feature idea

[Dj Gilcrease]

On Wed, Jun 2, 2010 at 3:14 PM, Jacob Kaplan-Moss  wrote:
> Aat EuroDjangoCon Russ and I discussed a "startup" mechanism that'd
> cover this use case, as well as a whole lot more. There's a few hints
> in the logging discussion a few threads down.
>
> So I'm -1 on this specific proposal, but only because I expect it to
> be obsoleted by me and Russ' startup proposal. Which one of us really
> should write up :)

Sounds good to me, my proposal was based on need and limited
understanding of the startup proposal based on the mentioning of it in
the logging thread where I assumed it would just be something like the
admin's auto discovery that looked for startup.py instead of admin.py

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Feature idea

[Jacob Kaplan-Moss]

On Wed, Jun 2, 2010 at 9:28 PM, Gregor Müllegger  wrote:
> I don't know much about the startup proposal, but I expect it to be a
> startup.py file in an application folder that gets loaded right after
> the django internals are ready and before the models have been loaded.
> The mechanism we ask for in this thread is something different.
>
> It would be nice to have a way to load modules from applications
> excatly like the startup.py file, but that the loading component is
> reusable and can be used for other modulenames specified by the app
> developer. This could be used by django.contrib.admin to load all
> admin.py files or by haystack to load all search_indexes.py files and
> so on.
>
> If this is also covered somehow by the startup proposal, just ignore
> me and I wait until this is written down somewhere.

Basically, the idea is that the app's startup handler could do any
auto-discovery on its own. So django.contrib.admin or Haystack or
whatever could provide a startup hook that just did the autodiscovery
there (or listened a signal to perform it later, more likely).

I'm trying to avoid having multiple "do things at startup" registries,
so having a "autodiscovery registry" along with a "logging startup"
along with the normal settings and app loading just starts to sound
like a bunch of different "do this at startup" cases. I'd like to kill
all these birds with one stone.

Again, I'll try to write up a startup proposal more completely, and
when I do you can see if it matches your usecase. I think it does,
though.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Feature idea

[Gregor Müllegger]

Hi Jacob,

I don't know much about the startup proposal, but I expect it to be a
startup.py file in an application folder that gets loaded right after
the django internals are ready and before the models have been loaded.
The mechanism we ask for in this thread is something different.

It would be nice to have a way to load modules from applications
excatly like the startup.py file, but that the loading component is
reusable and can be used for other modulenames specified by the app
developer. This could be used by django.contrib.admin to load all
admin.py files or by haystack to load all search_indexes.py files and
so on.

If this is also covered somehow by the startup proposal, just ignore
me and I wait until this is written down somewhere.
Thanks.

--
Servus,
Gregor Müllegger

2010/6/2 Jacob Kaplan-Moss :
> Aat EuroDjangoCon Russ and I discussed a "startup" mechanism that'd
> cover this use case, as well as a whole lot more. There's a few hints
> in the logging discussion a few threads down.
>
> So I'm -1 on this specific proposal, but only because I expect it to
> be obsoleted by me and Russ' startup proposal. Which one of us really
> should write up :)
>
> Jacob
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Feature idea

[Jacob Kaplan-Moss]

Aat EuroDjangoCon Russ and I discussed a "startup" mechanism that'd
cover this use case, as well as a whole lot more. There's a few hints
in the logging discussion a few threads down.

So I'm -1 on this specific proposal, but only because I expect it to
be obsoleted by me and Russ' startup proposal. Which one of us really
should write up :)

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: exception handling memory leak...

[Jacob Kaplan-Moss]

On Mon, May 31, 2010 at 4:07 AM, Kevin howerton
 wrote:
> http://code.djangoproject.com/ticket/10758
>
> Can we fix this?  It's a pretty easy fix.

I really don't want to be a jerk here, but this is precisely the
*wrong* way to go about getting work. Reminders are okay, but little
"pings" like this that (a) add no extra information and (b) don't
actually serve to advance things just come across as nagging.

Please try to remember that all of us are already spending as much
time on Django as we can (or too much, if you ask our significant
others :). We fix what we have time for; everything else we rely on
your help.

The *right* way to move things forward is to, well, *move things forward*.

This particular ticket:

* Has no patch.
* Has no test.
* Has a question in the ticket (about catching `Exception` instead of
`KeyboardInterrupt`) that needs answering.
* Needs review to see if the code in question has changed in the last year.

If you want to move things along, you could tackle any or all of the above.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: FK Autocomplete Widget [GSoC '09 Admin UI Improvements]

[Thomas Schreiber]

+1 for JqueryUI, it has come a long way in the last year, and it now has a
nice system for subclassing widgets with the widget factory.
http://bililite.com/blog/extending-jquery-ui-widgets/

-Thomas

On Wed, Jun 2, 2010 at 18:45, Jannis Leidel  wrote:

> > To me that would be a nice feature addition.  It does, however, bring
> > into question the fact that a widget, intending to be used on the
> > public side, would depend on jQuery for its UI.  Is Django ready to go
> > there?  Or would an admin-only autocomplete widget be preferred?
>
> The jQuery based ForeignKey widget was part of the adminui refactor and
> only for this use case discussed. It did have a bunch of side effects that
> prevented a timely merge before the 1.2 feature freeze, but we should now
> restart the efforts in my opinion.
>
> > Also, at the time, many of the jQuery autocomplete widgets were in a
> > state of flux or had some warts.  Our (Jannis and my) idea at the time
> > was to write our own from scratch, custom and optimized for Django.
> > That looks to be about a year ago so the state of things is probably
> > much different today.  (Or not?)
>
> At the time we hadn't a good (or 'stable') autocompletion plugin that would
> fit our needs. Now that the autocomplete feature is part of jQuery UI, maby
> we should review it again and see if it'd help us. In any case, there is of
> course the issue of an admin ManyToMany widget that should be dealt with at
> the same time.
>
> Jannis
>
> > On Wed, Jun 2, 2010 at 7:13 AM, Sergej dergatsjev eecho
> >  wrote:
> >> Current Admin Extensions
> >>
> >> ForeignKeyAutocompleteAdmin - ForeignKeyAutocompleteAdmin will enable
> >> the admin app to show ForeignKey fields with an search input field.
> >> The search field is rendered by the ForeignKeySearchInput form widget
> >> and uses jQuery to do configureable autocompletion.
> >>
> >> http://code.google.com/p/django-command-extensions/
> >>
> >>
> >> 2010/6/2 bydesign :
> >>> I second the vote to add the GSoC '09 Admin UI foreign key
> >>> autocomplete! It's actually somewhat embarrassing that this
> >>> functionality hasn't made it in yet. Foreign keys in the admin
> >>> interface become unusable if you have more than 50 or so rows in the
> >>> table. I hope that since this code has already been written and
> >>> tested, it can be included very soon!
> >>>
> >>>
> >>> On Jun 1, 9:30 am, Russell Keith-Magee 
> >>> wrote:
>  On Thu, May 27, 2010 at 8:26 PM, Philipp Metzler 
> wrote:
> > hello,
> 
> > i'm looking for exactely the same solution for an "Ajax foreign key
> > filter in the Django admin interface" and hoped it would be
> integrated
> > into the admin interface. I think it should be standard behaviour and
> > could be configurable in the admin.py Is the development of the admin
> > interface going in that direction or is it not planned at all?
> 
>  We're at the start of a development cycle, so the plans for the next
>  release haven't been finalised yet (beyond the broad guideline that it
>  will be a feature-light, bugfix heavy release). If this is an area
>  where you would like to see improvements, feel free to make a specific
>  proposal (preferably one accompanied by sample code :-)
> 
>  Yours,
>  Russ Magee %-)
> >>>
> >>> --
> >>> You received this message because you are subscribed to the Google
> Groups "Django developers" group.
> >>> To post to this group, send email to
> django-develop...@googlegroups.com.
> >>> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> >>> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
> >>>
> >>>
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups "Django developers" group.
> >> To post to this group, send email to django-developers@googlegroups.com
> .
> >> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> >> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
> >>
> >>
> >
> >
> >
> > --
> > -Rob
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> > To post to this group, send email to django-develop...@googlegroups.com.
> > To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> > For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email 

Re: FK Autocomplete Widget [GSoC '09 Admin UI Improvements]

[Jannis Leidel]

> To me that would be a nice feature addition.  It does, however, bring
> into question the fact that a widget, intending to be used on the
> public side, would depend on jQuery for its UI.  Is Django ready to go
> there?  Or would an admin-only autocomplete widget be preferred?

The jQuery based ForeignKey widget was part of the adminui refactor and only 
for this use case discussed. It did have a bunch of side effects that prevented 
a timely merge before the 1.2 feature freeze, but we should now restart the 
efforts in my opinion.

> Also, at the time, many of the jQuery autocomplete widgets were in a
> state of flux or had some warts.  Our (Jannis and my) idea at the time
> was to write our own from scratch, custom and optimized for Django.
> That looks to be about a year ago so the state of things is probably
> much different today.  (Or not?)

At the time we hadn't a good (or 'stable') autocompletion plugin that would fit 
our needs. Now that the autocomplete feature is part of jQuery UI, maby we 
should review it again and see if it'd help us. In any case, there is of course 
the issue of an admin ManyToMany widget that should be dealt with at the same 
time.

Jannis

> On Wed, Jun 2, 2010 at 7:13 AM, Sergej dergatsjev eecho
>  wrote:
>> Current Admin Extensions
>> 
>> ForeignKeyAutocompleteAdmin - ForeignKeyAutocompleteAdmin will enable
>> the admin app to show ForeignKey fields with an search input field.
>> The search field is rendered by the ForeignKeySearchInput form widget
>> and uses jQuery to do configureable autocompletion.
>> 
>> http://code.google.com/p/django-command-extensions/
>> 
>> 
>> 2010/6/2 bydesign :
>>> I second the vote to add the GSoC '09 Admin UI foreign key
>>> autocomplete! It's actually somewhat embarrassing that this
>>> functionality hasn't made it in yet. Foreign keys in the admin
>>> interface become unusable if you have more than 50 or so rows in the
>>> table. I hope that since this code has already been written and
>>> tested, it can be included very soon!
>>> 
>>> 
>>> On Jun 1, 9:30 am, Russell Keith-Magee 
>>> wrote:
 On Thu, May 27, 2010 at 8:26 PM, Philipp Metzler  wrote:
> hello,
 
> i'm looking for exactely the same solution for an "Ajax foreign key
> filter in the Django admin interface" and hoped it would be integrated
> into the admin interface. I think it should be standard behaviour and
> could be configurable in the admin.py Is the development of the admin
> interface going in that direction or is it not planned at all?
 
 We're at the start of a development cycle, so the plans for the next
 release haven't been finalised yet (beyond the broad guideline that it
 will be a feature-light, bugfix heavy release). If this is an area
 where you would like to see improvements, feel free to make a specific
 proposal (preferably one accompanied by sample code :-)
 
 Yours,
 Russ Magee %-)
>>> 
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "Django developers" group.
>>> To post to this group, send email to django-develop...@googlegroups.com.
>>> To unsubscribe from this group, send email to 
>>> django-developers+unsubscr...@googlegroups.com.
>>> For more options, visit this group at 
>>> http://groups.google.com/group/django-developers?hl=en.
>>> 
>>> 
>> 
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>> To post to this group, send email to django-develop...@googlegroups.com.
>> To unsubscribe from this group, send email to 
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group at 
>> http://groups.google.com/group/django-developers?hl=en.
>> 
>> 
> 
> 
> 
> -- 
> -Rob
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: FK Autocomplete Widget [GSoC '09 Admin UI Improvements]

[Jeremy Dunck]

On Wed, Jun 2, 2010 at 11:20 AM, Rob Hudson  wrote:
> Also, at the time, many of the jQuery autocomplete widgets were in a
> state of flux or had some warts.  Our (Jannis and my) idea at the time
> was to write our own from scratch, custom and optimized for Django.
> That looks to be about a year ago so the state of things is probably
> much different today.  (Or not?)


jQuery UI 1.8 newly ships with an autocomplete widget:
http://jqueryui.com/demos/autocomplete/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: FK Autocomplete Widget [GSoC '09 Admin UI Improvements]

[Rob Hudson]

If I recall correctly, there's another branch on the that project that
was refactoring the autocomplete widgets so that there were
essentially 2 widgets:  A widget intended to be used in your own
Django code, and an admin widget that was a subclass for use in the
admin.

To me that would be a nice feature addition.  It does, however, bring
into question the fact that a widget, intending to be used on the
public side, would depend on jQuery for its UI.  Is Django ready to go
there?  Or would an admin-only autocomplete widget be preferred?

Also, at the time, many of the jQuery autocomplete widgets were in a
state of flux or had some warts.  Our (Jannis and my) idea at the time
was to write our own from scratch, custom and optimized for Django.
That looks to be about a year ago so the state of things is probably
much different today.  (Or not?)

-Rob

On Wed, Jun 2, 2010 at 7:13 AM, Sergej dergatsjev eecho
 wrote:
> Current Admin Extensions
>
> ForeignKeyAutocompleteAdmin - ForeignKeyAutocompleteAdmin will enable
> the admin app to show ForeignKey fields with an search input field.
> The search field is rendered by the ForeignKeySearchInput form widget
> and uses jQuery to do configureable autocompletion.
>
> http://code.google.com/p/django-command-extensions/
>
>
> 2010/6/2 bydesign :
>> I second the vote to add the GSoC '09 Admin UI foreign key
>> autocomplete! It's actually somewhat embarrassing that this
>> functionality hasn't made it in yet. Foreign keys in the admin
>> interface become unusable if you have more than 50 or so rows in the
>> table. I hope that since this code has already been written and
>> tested, it can be included very soon!
>>
>>
>> On Jun 1, 9:30 am, Russell Keith-Magee 
>> wrote:
>>> On Thu, May 27, 2010 at 8:26 PM, Philipp Metzler  wrote:
>>> > hello,
>>>
>>> > i'm looking for exactely the same solution for an "Ajax foreign key
>>> > filter in the Django admin interface" and hoped it would be integrated
>>> > into the admin interface. I think it should be standard behaviour and
>>> > could be configurable in the admin.py Is the development of the admin
>>> > interface going in that direction or is it not planned at all?
>>>
>>> We're at the start of a development cycle, so the plans for the next
>>> release haven't been finalised yet (beyond the broad guideline that it
>>> will be a feature-light, bugfix heavy release). If this is an area
>>> where you would like to see improvements, feel free to make a specific
>>> proposal (preferably one accompanied by sample code :-)
>>>
>>> Yours,
>>> Russ Magee %-)
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>> To post to this group, send email to django-develop...@googlegroups.com.
>> To unsubscribe from this group, send email to 
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group at 
>> http://groups.google.com/group/django-developers?hl=en.
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>



-- 
-Rob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: First-class WSGI support in Django 1.3 / twod.wsgi

[Russell Keith-Magee]

On Sun, May 30, 2010 at 2:07 AM, Gustavo Narea  wrote:
> Hello,
>
> On May 28, 6:13 pm, Russell Keith-Magee 
> wrote:
>> This is all very helpful information; thanks for breaking it down like this.
>>
>> I've talked this over with a few people at the sprints, and we've
>> pretty much ended up at the same point -- we're deeply confused.
>> Comments inline below.
>
> Thank you very much for taking time to talk about it. :)
>
> Sorry, I think I didn't explain some components well and that led to
> the confusion. I'll try to do it better this time...
>
>> I also want to be very clear -- this feedback is *not* us saying "go
>> away", it's us saying "we're not clear on what you're proposing and
>> why you're proposing it". Please take this criticism in the sprit it
>> is intended -- to work out exactly what it is that we *aren't* doing,
>> and more importantly, *why* we should be doing it another way.
>
> Sure, I understand.
>
>> So - what you seem to be proposing here is that we add Paste as a
>> dependency of Django in order to support:
>>
>>  1) A format of configuration that is different to Django's
>>  2) Support for WSGI middlewares in the development server
>
> That's right, although the proposal is not mainly to add Paste as a
> dependency, but support WSGI middleware in a transparent way; for
> example, the way Paste Deploy does.

The issue I'm unclear on is what you mean by "transparent". Django
provides an interface that implements the WSGI spec. There may well be
errors in that implementation or violations of the spec, and if there
are, I'm happy to address them. But ultimately, we either implement
the spec or we don't.

If Django's implementation of the WSGI spec is compliant, but you
can't use it with out WSGI components, then to my reading either the
other components aren't implementing the spec, or the WSGI spec is
missing something big.

> The reason why I proposed Paste is because it's widely used and it'd
> prevent us from implementing something that is already implemented.

Your argument also presupposes that Paste is an inherently better
implementation. Well, I don't wan't to brag, but Django also has an
implemented WSGI implementation, and it's just as battle hardened as
Paste. :-)

I won't argue that duplication of code and effort is a virtue. If
there is a benefit to be gained in leveraging someone else's work, and
we can do so without compromising our own project, then we should.
However, this raises the much larger issue of how to manage Django's
relationship with external libraries in a way that maintains our
'beginner friendly' history. The 'minimal dependency' philosophy is,
in my opinion, one of the reasons that Django has been able to get the
traction that it has gained.

There have been some initial discussions about this general problem --
specifically, in relation to introducing support for unittest2.
However, it's a discussion that is much larger than improving WSGI
support, and it's a discussion that we need to have as a community.

>> (2) isn't a matter of opinion; however, it's not a use case that I've
>> seen a particularly compelling use case for, either. I'm certainly
>> willing to be convinced otherwise, though -- now is your opportunity
>> to convince us.
>
> Basically, when you need to integrate a piece of WSGI middleware that
> must be present both on development and deployment, you have to get
> rid of `manage runserver' and use a development server like the one
> from Paste or CherryPy.

Sure - if you have a complex deployment (by which I mean "anything
other than a single Django project and some static files"), you need
to have a complex deployment scheme. I don't see anything unusual in
that. Django ships a development server as a "getting started fast"
hack; it's not intended to be anything remotely approaching a useful
web server, and we're going to resist any attempts to turn it into
one. Django isn't a web server, and the development server isn't
intended for production use.

> There are lots of WSGI middleware out there that you may want/need to
> use, and there are even projects like Paste or Repoze whose only goal
> is to develop framework-independent WSGI libraries (many if not most
> of them are middleware). In the following links you can find some of
> the WSGI middleware available and find that most of them are
> applicable to both development and deployment:
> http://pythonpaste.org/modindex.html (some items aren't middleware,
> but WSGI applications)
> http://repoze.org/repoze_components.html#middleware
> http://wsgi.org/wsgi/Middleware_and_Utilities
>
> Some of them are alternatives to components offered by Django itself,
> which some people might prefer to use. Others are just things that
> cannot/shouldn't be done at the framework level.
>
> I'll give you one real-world example:
>
> We don't put all the static files under MEDIA_ROOT for the limitations
> described on 

Re: Class based generic views in 1.3?

[Roald]

Maybe I've missed the reason, or it's just too late to change, but why
not using a class itself (so basically its __init__ method) as a view.
I'm using something like this in my projects (as a base class):

class View(HttpRequest):
def __init__(self, request, *args, **kwargs):
...
super(View, self).__init__(self.content())
...

You can find it (the commit at time of writing) on
http://github.com/roalddevries/class_based_views/blob/10b5e4016c755164c20126f14870c41dc88b9c03/views.py.

An advantage of this is that url patterns of the form ('...', my_view)
can be user, where my_view is just a class derived from View. I also
think that the solution to redirection (lines 32-39) is pretty
elegant.

I'm looking forward to your comments.

Cheers, Roald

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: FK Autocomplete Widget [GSoC '09 Admin UI Improvements]

[Sergej dergatsjev eecho]

Current Admin Extensions

ForeignKeyAutocompleteAdmin - ForeignKeyAutocompleteAdmin will enable
the admin app to show ForeignKey fields with an search input field.
The search field is rendered by the ForeignKeySearchInput form widget
and uses jQuery to do configureable autocompletion.

http://code.google.com/p/django-command-extensions/


2010/6/2 bydesign :
> I second the vote to add the GSoC '09 Admin UI foreign key
> autocomplete! It's actually somewhat embarrassing that this
> functionality hasn't made it in yet. Foreign keys in the admin
> interface become unusable if you have more than 50 or so rows in the
> table. I hope that since this code has already been written and
> tested, it can be included very soon!
>
>
> On Jun 1, 9:30 am, Russell Keith-Magee 
> wrote:
>> On Thu, May 27, 2010 at 8:26 PM, Philipp Metzler  wrote:
>> > hello,
>>
>> > i'm looking for exactely the same solution for an "Ajax foreign key
>> > filter in the Django admin interface" and hoped it would be integrated
>> > into the admin interface. I think it should be standard behaviour and
>> > could be configurable in the admin.py Is the development of the admin
>> > interface going in that direction or is it not planned at all?
>>
>> We're at the start of a development cycle, so the plans for the next
>> release haven't been finalised yet (beyond the broad guideline that it
>> will be a feature-light, bugfix heavy release). If this is an area
>> where you would like to see improvements, feel free to make a specific
>> proposal (preferably one accompanied by sample code :-)
>>
>> Yours,
>> Russ Magee %-)
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: FK Autocomplete Widget [GSoC '09 Admin UI Improvements]

[bydesign]

I second the vote to add the GSoC '09 Admin UI foreign key
autocomplete! It's actually somewhat embarrassing that this
functionality hasn't made it in yet. Foreign keys in the admin
interface become unusable if you have more than 50 or so rows in the
table. I hope that since this code has already been written and
tested, it can be included very soon!


On Jun 1, 9:30 am, Russell Keith-Magee 
wrote:
> On Thu, May 27, 2010 at 8:26 PM, Philipp Metzler  wrote:
> > hello,
>
> > i'm looking for exactely the same solution for an "Ajax foreign key
> > filter in the Django admin interface" and hoped it would be integrated
> > into the admin interface. I think it should be standard behaviour and
> > could be configurable in the admin.py Is the development of the admin
> > interface going in that direction or is it not planned at all?
>
> We're at the start of a development cycle, so the plans for the next
> release haven't been finalised yet (beyond the broad guideline that it
> will be a feature-light, bugfix heavy release). If this is an area
> where you would like to see improvements, feel free to make a specific
> proposal (preferably one accompanied by sample code :-)
>
> Yours,
> Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Decision for ticket #6362 - Remove blank spaces with strip when validating the data

[Steven Davidson]

Loving v1.2, my first experience with Django: thanks for all the hard work!

However this issue has bitten me twice now. I know it is entirely my
responsibility to validate and clean user input as required but I really
can't think of a valid use case where trailing white space would occur. Also
it can snag a 'feature' in MySQL with unique indexes ignoring trailing
spaces for comparison purposes.

Any chance of a decision on whether this should appear in 1.3 and in what
form?

Thanks,
Steven.


-- Forwarded message --

> From: Wes Winham 
> Date: Oct 15 2009, 9:35 pm
> Subject: Decision for ticket #6362 - Remove blank spaces with strip
> when validating the data
> To: Django developers
>
>
> The common use case on my projects is definitely to trim whitespace.
> The autostrip decorator I found on djangosnippets (http://
> www.djangosnippets.org/snippets/956/) is pretty awesome, but I'd
> prefer not to import that into every project and it would be nice to
> not call:
>
> > MyForm = autostrip(MyForm)
>
> on practically every form I have with a CharField
>
> What's the common use case for allowing a user to add a space at the
> end of a datetime field or email field, or pretty much any text field?
> It seems like that those situations are in the minority and thestrip
> argument would make things simpler for the simple case while remaining
> backwards compatible.
>
> -Wes
>
> On Oct 10, 5:47 pm, Taylor Marshall 
> wrote:
>
>
>
> > I'd love to see this change get put in.  I think the most common case
> > for forms is to trim whitespace, not the other way around.  I'd rather
> > have the extra work come in for the rare case (when you wanted to
> > preserve leading/trailingspaces).
>
> > -Taylor
>
> > On Oct 10, 11:37 am, Barry Pederson  wrote:
>
> > > On May 13, 2:56 am, Russell Keith-Magee 
> > > wrote:
> > >  >On Wed, May 13, 2009 at 7:48 AM, thebitguru 
> wrote:
>
> > >  >> Hi,
>
> > >  >> What do we need to make adecisionforticket6362(http://
> > >  >> code.djangoproject.com/ticket/6362)?
>
> > >  > We need to wait until we're not trying to get v1.1 out the door.
>
> > >  > We are well past the feature deadline for v1.1; the focus of the
> > >  > community is on fixing bugs and finalizing the v1.1 release. Once
> that
> > >  > happens, we will be in a position to concentrate on design decisions
> > >  > again.
>
> > > Now that we're talking about 1.2, I hope this can be looked at before
> > > the door closes again.  Either this or the simpler patch from
>
> > >http://code.djangoproject.com/ticket/4960
>
> > > Having extraneousspacesin user input is quite annoying and can cause a
> > > fair amount of trouble.  Yes, you could write custom validation for
> > > every single one of your forms, but a global fix is potentially pretty
> > > trivial.
>
> > > Some other tickets complaining about the same problem with specific
> > > field types are:
>
> > >http://code.djangoproject.com/ticket/5714
> > >http://code.djangoproject.com/ticket/11907
>
> > > Barry

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Project-wide cache prefix (low-level API)

[stefanw]

On Jun 2, 9:51 am, batiste  wrote:
> What about the problem that you can, in theory, use the same
> application several time (several instance) within the same project?

There is a Google Summer of Code Project 
http://code.djangoproject.com/wiki/SummerOfCode2010
that will hopefully take care of these issues.

Cheers,
Stefan

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: First-class WSGI support in Django 1.3 / twod.wsgi

[Gustavo Narea]

On Jun 2, 9:26 am, Reinout van Rees  wrote:
> On 05/29/2010 01:51 AM, Gustavo Narea wrote:
> > Basically, when you need to integrate a piece of WSGI middleware that
> > must be present both on development and deployment, you have to get
> > rid of `manage runserver' and use a development server like the one
> > from Paste or CherryPy.
>
> Middleware that *must* be present: it reminded me of an old blog post
> that warned about mandatory middleware. I think I've read it in more
> than one place, though:
>
> http://dirtsimple.org/2007/02/wsgi-middleware-considered-harmful.html
>
> The core idea of that post is that if something is mandatory, it isn't
> middleware anymore.  It should be part of your application.  I don't
> really have an opinion about this myself (yet).

I completely disagree with that, but regardless of what we think,
there are lots of middleware out there that expose an API that is used
inside the WSGI application, and doing so is so common that frameworks
like Pylons set up new projects like that. And Django developers may
need/want to use that kind of middleware.

> Do you know what the current way of thinking on this is?

I'm guessing that a very tiny portion of the people who use WSGI don't
like it, presumably because of the reasons described in that post from
2007.

 - Gustavo.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Feature idea

[Reinout van Rees]

On 06/01/2010 09:42 PM, Sean O'Connor wrote:

I've been generally thinking about putting together a package of
reusable tools to implement common "patterns" for reusable apps.
  Included in this would be this type of auto-discovery system as well
as a registration pattern.


Auto-discovery and registration: setuptools entry points can be used for 
this.  That at least is an existing (partial) solution.


I'm already using it in a django project where I've got a couple of 
packages that can register a render-something-on-a-map method.  In the 
one location where I need it I can then just ask setuptools (well, 
pkg_resources) for a list of methods and call them.


Just for the idea, here's a snippet from a setup.py:

  entry_points={
  'lizard_map.layer_method': [
'shapefile_layer = lizard_map.layers:shapefile_layer',
]
  },

And afterwards iterate through all the entry points and call them (or do 
something else with them):


for entrypoint in pkg_resources.iter_entry_points(
group="lizard_map.layer_method"):
method = entrypoint.load()
method("some argument)


Some longer explanation: http://tinyurl.com/ylf3kjb


Reinout


--
Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org
Programmer at http://www.nelen-schuurmans.nl
"Military engineers build missiles. Civil engineers build targets"

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Project-wide cache prefix (low-level API)

[batiste]

What about the problem that you can, in theory, use the same
application several time (several instance) within the same project?

I don't have a real use-case, but I have heard people doing it.

http://groups.google.com/group/django-users/browse_thread/thread/076f31a1a5479676/8d5f2e0f8f1e1957

Batiste

On Jun 2, 3:47 am, Byron  wrote:
> Yea, I definitely agree that it is a simple solution. I think the the
> fact that the setting is optional and would not break any existing
> code, it should be included since it "feels" like a common case... we
> shall leave it up to the core devs to determine this.
>
> On Jun 1, 7:14 pm, Gabriel Hurley  wrote:
>
>
>
> > Personally, I solved this by writing a wrapper around
> > django.utils.cache that can be dropped in transparently. It was a
> > really simple matter to have it take a cache prefix (in my case from
> > settings.py) and pass that into the original functions.
>
> > It's a pretty easy fix if the core team agrees that it's useful. Seems
> > like the debate might be more around adding another setting for it/
> > where/how to manage that prefix.
>
> > All the best,
>
> >     - Gabriel
>
> > On Jun 1, 8:12 am, Byron  wrote:
>
> > > I ran into a seemingly common problem with cache key conflicts between
> > > two projects that both share an app and the same memcache instance. I
> > > would imagine that being able to optionally set a PROJECT_CACHE_PREFIX
> > > that is prepended to every key when setting/getting would be a nice
> > > transparent way of ensuring there are no conflicts. Obviously if the
> > > behavior is to share cache between projects, then no prefix can be
> > > specified.
>
> > > I want to get initial feedback, implications, etc. on this before I
> > > start writing a patch.
>
> > > Thanks,
> > > -Byron

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: First-class WSGI support in Django 1.3 / twod.wsgi

[Reinout van Rees]

On 05/29/2010 01:51 AM, Gustavo Narea wrote:


Basically, when you need to integrate a piece of WSGI middleware that
must be present both on development and deployment, you have to get
rid of `manage runserver' and use a development server like the one
from Paste or CherryPy.


Middleware that *must* be present: it reminded me of an old blog post 
that warned about mandatory middleware. I think I've read it in more 
than one place, though:


http://dirtsimple.org/2007/02/wsgi-middleware-considered-harmful.html

The core idea of that post is that if something is mandatory, it isn't 
middleware anymore.  It should be part of your application.  I don't 
really have an opinion about this myself (yet).



Do you know what the current way of thinking on this is?


Reinout

--
Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org
Programmer at http://www.nelen-schuurmans.nl
"Military engineers build missiles. Civil engineers build targets"

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Feature idea

[burc...@gmail.com]

Hi Dj Gilcrease,

I've almost implemented kinda similar proposal (draft here:
http://groups.google.com/group/django-developers/browse_thread/thread/b7339d8577567d95
),

and what worries me, is that in current Django you just can't do
autodiscover of django contribs in settings.py because of circular
dependency on django.db.utils.

On Wed, Jun 2, 2010 at 1:43 AM, Dj Gilcrease  wrote:
> On Tue, Jun 1, 2010 at 3:02 PM, Gregor Müllegger  wrote:
>> My proposal would go into the direction of pulling the autodiscover
>> function out of the django.contrib.admin module and putting it
>> somewhere in the core. Since the admin needs some special
>> functionality on errors while loading an admin.py module from an app,
>> I would suggest a Autodiscover class that provides some hooks to be
>> better customizable.
>>
>> Something like:
> 
>
> I like this idea better then mine provided the startup.py proposal
> goes forward. I very much dislike having autodiscover stuff being
> loaded in urls.py as a hack to get an app bootstrapped and part of
> what I am trying to solve is the need for app consumers (End
> Developers) to bootstrap your app in urls.py.
>
>
> I figured a setting was slightly more explicit then the bit of magic
> that would go on by having your own autodiscover sub-class being
> initiated in startup.py (I really think that should be named
> bootstrap.py but I digress). Even with the setting there is nothing
> preventing you from adding your module to the autodiscover setting
> when you call your management command, but as I said I like the class
> approach provided a application bootstrap system is provided.
>
> If the class based approach is chosen then I think it should love in
> django.utils.autodiscover as it is something the application developer
> must subclass if they want to use it, and if it is in core I would
> expect it to be something used internally and only to be tinkered with
> by advanced users.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>



-- 
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.