Code

Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#17141 closed New feature (wontfix)

Placeholder images in contrib/webdesign

Reported by: anonymous Owned by: nobody
Component: contrib.webdesign Version: 1.3
Severity: Normal Keywords: placeholder, images, webdesign
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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] %}

Attachments (0)

Change History (3)

comment:1 Changed 3 years ago by russellm

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to wontfix
  • Status changed from new to closed

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.

comment:2 Changed 3 years ago by aaugustin

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"?

comment:3 Changed 3 years ago by russellm

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'.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.