Placeholder images in contrib/webdesign

[anonymous]

Placeholder images that can be automatically generated at the appropriate size is almost as useful as placeholder text.

Some web services for this already exists:
​http://placekitten.com/
​http://placehold.it/

It would be nice to have it in the webdesign package as well.

Suggested syntax:

{% placeholder_image [width] [height] [grayscale] %}

[Russell Keith-Magee]

I'm going to mark this as wontfix. The idea is certainly useful, but the dependence on an external web service is what has me concerned. The longevity and reliability of these services would impact on the stability of Django of a framework, and I'm not sure that's a position Django as a framework should be in.

This would be a really good candidate for a third-party tag library, however. For that matter, the webdesign tools as a whole would probably be better suited to being a third party app.

[Aymeric Augustin]

This was already requested in #16658 and rejected on the grounds of "reliance on external services".

That said, do we really have to use a third party service? It should be fairly easy to generate PNGs of a given size with PIL. Django already has an optional dependency on PIL (ImageField). If we did this, all you'd have to do to use the feature is add an URL pointing to django.webdesign.views.placeholder in your URL conf.

I believe that's what the OP had in mind, and not a wrapper around a third-party API.

I agree that this brings little value — the only real advantage compared to placehold.it is that you can develop offline. However, it fits reasonably with Django's philosophy and shouldn't be a maintenance burden. If a patch with a self-contained and simple implementation was submitted, wouldn't we reconsider the "wontfix"?

[Russell Keith-Magee]

Having to deploy a URL to support a placeholder sounds like overkill for me. By the time you've got the moving parts working, it would be easier to just look up the URL arguments to an external service of your choice.

However:

1) There was lots of talk at DjangoCon about shipping less with Django. The extreme case of this would be shipping contrib.auth as an external package; that's a way off being practical, but something like contrib.webdesign -- a package with a single template tag in it -- would be a good candidate for pruning. If someone wanted to take on contrib.webdesign as a third party project, I could get behind a move to prune it from the Django's tree, at which point, the new maintainer wouldn't be bound to Django's internal maintenance policies.

2) If we have to manually deploy a view in urls.py, it would be a pain. But what if there was a way for an app to automatically hook in URLs at a predictable location? This isn't an isolated use case, either; consider the case of AJAX widgets -- they need a way to register a data source that needs to be exposed as a view. There might be a need for a framework support for 'machine usable, internal URL endpoints'.