Inclusion of easy-thumbnails into Django Contrib
99 views
Skip to first unread message
Yo-Yo Ma
Sep 16, 2010, 1:00:26 AM9/16/10
to Django developers
Is there any plans to incorporate http://github.com/SmileyChris/easy-thumbnails/
into django.contrib? I have seen so many apps/libraries come into and
go out of existence (http://code.djangoproject.com/wiki/ThumbNails for
instance mentions sorl-thumbnails which is no longer being developed).
I just turned the key with easy-thumbnails and voila. It's like magic,
but not. It's easy enough to see what's going on behind the scenes.
This is something that, with the help of the core and other
contributors, could be really great. It works for me as it it is, but
it may not work for a more "enterprise" application that uses S3, etc.
It might not be highly efficient (I wouldn't know). It might have bugs
that I just haven't noticed yet. I'm mentioning all of this because I
know somebody will say, "Why move it into Django if it's doing just
fine as a separate project?". After experiencing the bliss I thought
I'd drop a line here about it, and see what you guys thought.
into django.contrib? I have seen so many apps/libraries come into and
go out of existence (http://code.djangoproject.com/wiki/ThumbNails for
instance mentions sorl-thumbnails which is no longer being developed).
I just turned the key with easy-thumbnails and voila. It's like magic,
but not. It's easy enough to see what's going on behind the scenes.
This is something that, with the help of the core and other
contributors, could be really great. It works for me as it it is, but
it may not work for a more "enterprise" application that uses S3, etc.
It might not be highly efficient (I wouldn't know). It might have bugs
that I just haven't noticed yet. I'm mentioning all of this because I
know somebody will say, "Why move it into Django if it's doing just
fine as a separate project?". After experiencing the bliss I thought
I'd drop a line here about it, and see what you guys thought.
David P. Novakovic
Sep 16, 2010, 1:09:37 AM9/16/10
to django-d...@googlegroups.com
I don't want to sound negative, but answering your own question before
anyone else can doesn't change the answer ;)
anyone else can doesn't change the answer ;)
D
> --
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To post to this group, send email to django-d...@googlegroups.com.
> To unsubscribe from this group, send email to django-develop...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
>
>
David P. Novakovic
Sep 16, 2010, 1:32:36 AM9/16/10
to django-d...@googlegroups.com
Actually, that really did sound negative. Sorry :)
Is there a trac ticket open to address this issue? Generally it'd be
better to get discussion happening over a ticket and if there are
serious issues that need to be addressed then they can be discussed
here.
I know it'd be nice to get things like easy-thumbnails accepted into
django.contrib , but the truth is that this probably falls outside of
things that that should be in contrib. Contrib isn't really an easier
way to get stuff into django, it still has to satisfy a bunch of
conditions like the rest of the code in the core.
The real question is not "can it be included?" but why is it a problem
that this is a third party lib at the moment? Is there a strong case
that it be better if it was part of django core or does it do its job
just fine the way it is now?
David
Yo-Yo Ma
Sep 16, 2010, 12:24:52 PM9/16/10
to Django developers
I have no data to support the following assertion, but it's not too
unreasonable: More people probably need thumbnail images than they
need comments. Comments are most used on blogs, whereas thumbnails can
be used on blogs, e-commerce, photo hosting, social networking,
project management, et al. It's not to say that we don't need
"contrib.comments", just that I wouldn't want to lose easy_thumbnails.
On Sep 15, 11:32 pm, "David P. Novakovic" <davidnovako...@gmail.com>
wrote:
> >> Is there any plans to incorporatehttp://github.com/SmileyChris/easy-thumbnails/
unreasonable: More people probably need thumbnail images than they
need comments. Comments are most used on blogs, whereas thumbnails can
be used on blogs, e-commerce, photo hosting, social networking,
project management, et al. It's not to say that we don't need
"contrib.comments", just that I wouldn't want to lose easy_thumbnails.
On Sep 15, 11:32 pm, "David P. Novakovic" <davidnovako...@gmail.com>
wrote:
> Actually, that really did sound negative. Sorry :)
>
> Is there a trac ticket open to address this issue? Generally it'd be
> better to get discussion happening over a ticket and if there are
> serious issues that need to be addressed then they can be discussed
> here.
>
> I know it'd be nice to get things like easy-thumbnails accepted into
> django.contrib , but the truth is that this probably falls outside of
> things that that should be in contrib. Contrib isn't really an easier
> way to get stuff into django, it still has to satisfy a bunch of
> conditions like the rest of the code in the core.
>
> The real question is not "can it be included?" but why is it a problem
> that this is a third party lib at the moment? Is there a strong case
> that it be better if it was part of django core or does it do its job
> just fine the way it is now?
>
> David
>
> On Thu, Sep 16, 2010 at 3:09 PM, David P. Novakovic
>
>
> Is there a trac ticket open to address this issue? Generally it'd be
> better to get discussion happening over a ticket and if there are
> serious issues that need to be addressed then they can be discussed
> here.
>
> I know it'd be nice to get things like easy-thumbnails accepted into
> django.contrib , but the truth is that this probably falls outside of
> things that that should be in contrib. Contrib isn't really an easier
> way to get stuff into django, it still has to satisfy a bunch of
> conditions like the rest of the code in the core.
>
> The real question is not "can it be included?" but why is it a problem
> that this is a third party lib at the moment? Is there a strong case
> that it be better if it was part of django core or does it do its job
> just fine the way it is now?
>
> David
>
> On Thu, Sep 16, 2010 at 3:09 PM, David P. Novakovic
>
> <davidnovako...@gmail.com> wrote:
> > I don't want to sound negative, but answering your own question before
> > anyone else can doesn't change the answer ;)
>
> > D
>
> > On Thu, Sep 16, 2010 at 3:00 PM, Yo-Yo Ma <baxterstock...@gmail.com> wrote:
> > I don't want to sound negative, but answering your own question before
> > anyone else can doesn't change the answer ;)
>
> > D
>
> >> Is there any plans to incorporatehttp://github.com/SmileyChris/easy-thumbnails/
Brian O'Connor
Sep 16, 2010, 12:33:14 PM9/16/10
to django-d...@googlegroups.com
I have absolutely no pull in decision making, but maybe my message will count towards a "community voice".
I think that including an image thumbnail package that integrates into the database as easily as sorl.thumbnail and easy_thumbnail are is a great idea. From what I can tell, sorl.thumbnail was the de facto standard for getting thumbnails in to Django, and I think it has just as much of a place in Django contrib as some of the other contrib apps do. I don't think it belongs in the core, but contrib seems like an excellent place for it to go along with the other batteries in the pack.--
Brian O'Connor
I think that including an image thumbnail package that integrates into the database as easily as sorl.thumbnail and easy_thumbnail are is a great idea. From what I can tell, sorl.thumbnail was the de facto standard for getting thumbnails in to Django, and I think it has just as much of a place in Django contrib as some of the other contrib apps do. I don't think it belongs in the core, but contrib seems like an excellent place for it to go along with the other batteries in the pack.
Brian O'Connor
Yo-Yo Ma
Sep 16, 2010, 12:37:03 PM9/16/10
to Django developers
sorl-thumbnails is over. The two developers who were maintaining it
have started to different projects. One relies on ImageMagik and is
probably not as easy for the crowds. The other is "easy-thumbnails".
> > django-develop...@googlegroups.com<django-developers%2Bunsu...@googlegroups.com>
> > .
> > .
have started to different projects. One relies on ImageMagik and is
probably not as easy for the crowds. The other is "easy-thumbnails".
> > .
> > > >> For more options, visit this group athttp://
> > groups.google.com/group/django-developers?hl=en.
>
> > 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-d...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-develop...@googlegroups.com<django-developers%2Bunsu...@googlegroups.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-d...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > .
Brian O'Connor
Sep 16, 2010, 12:41:50 PM9/16/10
to django-d...@googlegroups.com
Yeah, I'm aware, that's why I said '_was_ the de facto standard' :)
easy-thumbnails is what I had in mind when I was agreeing with you. I think it's a great piece of software that satisfies most people's needs for image manipulation within a web development environment, and being in contrib will allow people to use another package if they don't like it.
--
Brian O'Connor
easy-thumbnails is what I had in mind when I was agreeing with you. I think it's a great piece of software that satisfies most people's needs for image manipulation within a web development environment, and being in contrib will allow people to use another package if they don't like it.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
--
Brian O'Connor
Patrick Altman
Sep 16, 2010, 12:43:45 PM9/16/10
to django-d...@googlegroups.com
Another "community voice" contribution on this thread...
I am of the opposite opinion. I think it would be better for Django as a whole if django.contrib approached zero. In fact, I would have no problem with seeing it go away completely and promote auth and sessions to core but done in a way that is pluggable. The reasoning behind this opinion is that it leaves the surface area in the project smaller to maintain and it's really not that hard to add a sorl-thumbnail external app to a Django project. Furthermore, it provides more freedom for these apps to mature and develop at their own pace.
I realize I could very well be in a minority opinion here, but thought I'd throw it into the mix nonetheless.
Chuck Harmston
Sep 16, 2010, 12:55:28 PM9/16/10
to django-d...@googlegroups.com
There's a negative side to contrib: once an app is included, it stifles innovation on that particular app (because it is tied to release cycles and must maintain full backwards compatibility) and discourages other developers from innovating in that same area.
In order to get an application included to contrib, you'll need to make a compelling case that the community will gain by its inclusion in contrib. Yes, easy-thumbnails is great, but the only argument you've provided is that you don't want development to die, as it did on sorl_thumbnails (which is still a functional piece of software, by the way). That's a legitimate fear, but where do you draw the line? What about django-registration? Or django-taggit?
Further discussion from DjangoCon (skip ahead to 22:12 for discussion on contrib, though I recommend the entire talk): http://djangocon.blip.tv/file/4112452/
Yo-Yo Ma
Sep 16, 2010, 1:13:07 PM9/16/10
to Django developers
I see what you're saying Chuck. It's almost like you stop evolution
(natural selection, if you will) when you accept a "winner" for the
trunk. The positive to weigh against is that you remove instability
form external projects like this. It's a great project, but it could
turn south quickly without being fully supported. To be honest, I'm
even on the fence myself, but it's worth mentioning for others to
weigh in.
On Sep 16, 10:55 am, Chuck Harmston <ch...@chuckharmston.com> wrote:
> There's a negative side to contrib: once an app is included, it stifles
> innovation on that particular app (because it is tied to release cycles and
> must maintain full backwards compatibility) and discourages other developers
> from innovating in that same area.
>
> In order to get an application included to contrib, you'll need to make a
> compelling case that the community will gain by its inclusion in contrib.
> Yes, easy-thumbnails is great, but the only argument you've provided is that
> you don't want development to die, as it did on sorl_thumbnails (which is
> still a functional piece of software, by the way). That's a legitimate fear,
> but where do you draw the line? What about django-registration? Or
> django-taggit?
>
> Further discussion from DjangoCon (skip ahead to 22:12 for discussion on
> contrib, though I recommend the entire talk):http://djangocon.blip.tv/file/4112452/
>
> >> <django-developers%2Bunsu...@googlegroups.com<django-developers%252Buns...@googlegroups.com>
> *
> ---
> Chuck Harmston*
> ch...@chuckharmston.comhttp://chuckharmston.com
(natural selection, if you will) when you accept a "winner" for the
trunk. The positive to weigh against is that you remove instability
form external projects like this. It's a great project, but it could
turn south quickly without being fully supported. To be honest, I'm
even on the fence myself, but it's worth mentioning for others to
weigh in.
On Sep 16, 10:55 am, Chuck Harmston <ch...@chuckharmston.com> wrote:
> There's a negative side to contrib: once an app is included, it stifles
> innovation on that particular app (because it is tied to release cycles and
> must maintain full backwards compatibility) and discourages other developers
> from innovating in that same area.
>
> In order to get an application included to contrib, you'll need to make a
> compelling case that the community will gain by its inclusion in contrib.
> Yes, easy-thumbnails is great, but the only argument you've provided is that
> you don't want development to die, as it did on sorl_thumbnails (which is
> still a functional piece of software, by the way). That's a legitimate fear,
> but where do you draw the line? What about django-registration? Or
> django-taggit?
>
> Further discussion from DjangoCon (skip ahead to 22:12 for discussion on
> contrib, though I recommend the entire talk):http://djangocon.blip.tv/file/4112452/
>
> On Thu, Sep 16, 2010 at 12:41 PM, Brian O'Connor <gatzby...@gmail.com>wrote:
>
>
>
> > Yeah, I'm aware, that's why I said '_was_ the de facto standard' :)
>
> > easy-thumbnails is what I had in mind when I was agreeing with you. I
> > think it's a great piece of software that satisfies most people's needs for
> > image manipulation within a web development environment, and being in
> > contrib will allow people to use another package if they don't like it.
>
>
>
>
> > Yeah, I'm aware, that's why I said '_was_ the de facto standard' :)
>
> > easy-thumbnails is what I had in mind when I was agreeing with you. I
> > think it's a great piece of software that satisfies most people's needs for
> > image manipulation within a web development environment, and being in
> > contrib will allow people to use another package if they don't like it.
>
>
> >> > > .
> >> > > > >> For more options, visit this group athttp://
> >> > > 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-d...@googlegroups.com.
> >> > > To unsubscribe from this group, send email to
> >> > > django-develop...@googlegroups.com<django-developers%2Bunsu...@googlegroups.com>
> >> <django-developers%2Bunsu...@googlegroups.com<django-developers%252Buns...@googlegroups.com>
> >> > > .
> >> > > > >> For more options, visit this group athttp://
> >> > > 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-d...@googlegroups.com.
> >> > > To unsubscribe from this group, send email to
> >> > > django-develop...@googlegroups.com<django-developers%2Bunsu...@googlegroups.com>
> ---
> Chuck Harmston*
> ch...@chuckharmston.comhttp://chuckharmston.com
ptone
Sep 16, 2010, 1:26:29 PM9/16/10
to Django developers
On Sep 16, 9:43 am, Patrick Altman <palt...@gmail.com> wrote:
> Another "community voice" contribution on this thread...
>
> I am of the opposite opinion. I think it would be better for Django as a whole if django.contrib approached zero. In fact, I would have no problem with seeing it go away completely and promote auth and sessions to core but done in a way that is pluggable. The reasoning behind this opinion is that it leaves the surface area in the project smaller to maintain and it's really not that hard to add a sorl-thumbnail external app to a Django project. Furthermore, it provides more freedom for these apps to mature and develop at their own pace.
>
> I realize I could very well be in a minority opinion here, but thought I'd throw it into the mix nonetheless.
My hope is that one day http://djangopackages.com/ will become
packages.djangoproject.com
(and along with that a management command startapp-dist which starts a
distributable skeleton)
-Preston
>
> On Sep 16, 2010, at 11:33 AM, Brian O'Connor wrote:
>
>
>
> > I have absolutely no pull in decision making, but maybe my message will count towards a "community voice".
>
> > I think that including an image thumbnail package that integrates into the database as easily as sorl.thumbnail and easy_thumbnail are is a great idea. From what I can tell, sorl.thumbnail was the de facto standard for getting thumbnails in to Django, and I think it has just as much of a place in Django contrib as some of the other contrib apps do. I don't think it belongs in the core, but contrib seems like an excellent place for it to go along with the other batteries in the pack.
>
Justin Lilly
Sep 16, 2010, 1:35:05 PM9/16/10
to django-d...@googlegroups.com
One of the criteria for django.contrib is that the item for inclusion
is a "de facto standard implementation of common patterns"[0]. From
your own admittance there are conflicting views about how this should
be handled. Perhaps if someone abstracts this out a bit and has
something like image processing backends, it may make a bit more sense
for inclusion, but as it stands, I'm -1.
is a "de facto standard implementation of common patterns"[0]. From
your own admittance there are conflicting views about how this should
be handled. Perhaps if someone abstracts this out a bit and has
something like image processing backends, it may make a bit more sense
for inclusion, but as it stands, I'm -1.
-justin
[0]: http://jacobian.org/writing/what-is-django-contrib/
bur...@gmail.com
Sep 16, 2010, 3:53:36 PM9/16/10
to django-d...@googlegroups.com
Hi everyone,
I think thumbnailing functionality is much closer to django core
rather than to django.contrib, and that is the most important reason
for inclusion.
Django provides ImageField out of the box, but why it doesn't provide
ThumbnailImageField out of the box?
Django provides {% lorem %} tag, but why it doesn't provide {%
thumbnail %} tag?
Thumbnails are very common pattern.
Maybe this application (easy_thumbnails) is not the best choice, but
the general idea of having good and popular reusable thumbnail
solution distributed with django is very attractive to me.
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com
David P. Novakovic
Sep 16, 2010, 5:39:52 PM9/16/10
to django-d...@googlegroups.com
FWIW +1 for moving away from contrib for me.
Let the core focus on core functionality and people who both more
qualified and passionate about "contrib" pieces to manage that
functionality without being burdened by the core release cycle
patterns.
D
Benoit
Sep 16, 2010, 5:44:18 PM9/16/10
to django-d...@googlegroups.com
I also agree moving away from contrib. Even comments aren't actually necessary and could be a third party project.
Benoit
Benoit
Yo-Yo Ma
Sep 16, 2010, 5:51:55 PM9/16/10
to Django developers
I have to pull out my flip flops. Last week I read the slides from the
orange haired guy (Alex I believe), "Why Django sucks...", and found
it interesting. Today I watched it, and maybe I'm just an audio
learning sort of guy, but I am truly sold on the idea of focusing on
the core APIs to make developing your own plugins easier, and leaving
those plugins out of the core or contrib. That's not to say I would
like to have thumbnailing built in still, but in the interest of the
greater good I now officially "flip flop". I think Alex made some
really compelling arguments. If Django as a core web framework worked
way better (It's excellent now, but it could be better performing,
upgraded quicker, easier to plug things into (more modularity at some
levels), and acted only as an ORM / Template / Sessions framework at
some future point, perhaps the satelite projects (such as "easy-
thumbnails") would be more plentiful and better. More competition
equals better quality (or price fixing, but I digress). Today I
visited http://djangopackages.com/ (linked above) for the first time.
This sort of things is excellent and promotes progress, without
halting evolution just to make the whiners (ie, me 1 hour ago) happy
with cheap built-ins. Gosh, I really pulled a John Kerry on this one;
sorry.
My vote on my own idea is -2 (one to reverse the initial proposal)
On Sep 16, 3:39 pm, "David P. Novakovic" <davidnovako...@gmail.com>
wrote:
orange haired guy (Alex I believe), "Why Django sucks...", and found
it interesting. Today I watched it, and maybe I'm just an audio
learning sort of guy, but I am truly sold on the idea of focusing on
the core APIs to make developing your own plugins easier, and leaving
those plugins out of the core or contrib. That's not to say I would
like to have thumbnailing built in still, but in the interest of the
greater good I now officially "flip flop". I think Alex made some
really compelling arguments. If Django as a core web framework worked
way better (It's excellent now, but it could be better performing,
upgraded quicker, easier to plug things into (more modularity at some
levels), and acted only as an ORM / Template / Sessions framework at
some future point, perhaps the satelite projects (such as "easy-
thumbnails") would be more plentiful and better. More competition
equals better quality (or price fixing, but I digress). Today I
visited http://djangopackages.com/ (linked above) for the first time.
This sort of things is excellent and promotes progress, without
halting evolution just to make the whiners (ie, me 1 hour ago) happy
with cheap built-ins. Gosh, I really pulled a John Kerry on this one;
sorry.
My vote on my own idea is -2 (one to reverse the initial proposal)
On Sep 16, 3:39 pm, "David P. Novakovic" <davidnovako...@gmail.com>
wrote:
> FWIW +1 for moving away from contrib for me.
>
> Let the core focus on core functionality and people who both more
> qualified and passionate about "contrib" pieces to manage that
> functionality without being burdened by the core release cycle
> patterns.
>
> D
>
>
> Let the core focus on core functionality and people who both more
> qualified and passionate about "contrib" pieces to manage that
> functionality without being burdened by the core release cycle
> patterns.
>
> D
>
> On Fri, Sep 17, 2010 at 5:53 AM, burc...@gmail.com <burc...@gmail.com> wrote:
> > Hi everyone,
>
> > I think thumbnailing functionality is much closer to django core
> > rather than to django.contrib, and that is the most important reason
> > for inclusion.
>
> > Django provides ImageField out of the box, but why it doesn't provide
> > ThumbnailImageField out of the box?
> > Django provides {% lorem %} tag, but why it doesn't provide {%
> > thumbnail %} tag?
>
> > Thumbnails are very common pattern.
>
> > Maybe this application (easy_thumbnails) is not the best choice, but
> > the general idea of having good and popular reusable thumbnail
> > solution distributed with django is very attractive to me.
>
> > On Fri, Sep 17, 2010 at 12:35 AM, Justin Lilly <jus...@justinlilly.com> wrote:
> >> One of the criteria for django.contrib is that the item for inclusion
> >> is a "de facto standard implementation of common patterns"[0]. From
> >> your own admittance there are conflicting views about how this should
> >> be handled. Perhaps if someone abstracts this out a bit and has
> >> something like image processing backends, it may make a bit more sense
> >> for inclusion, but as it stands, I'm -1.
>
> >> -justin
>
> >> [0]:http://jacobian.org/writing/what-is-django-contrib/
>
> > Hi everyone,
>
> > I think thumbnailing functionality is much closer to django core
> > rather than to django.contrib, and that is the most important reason
> > for inclusion.
>
> > Django provides ImageField out of the box, but why it doesn't provide
> > ThumbnailImageField out of the box?
> > Django provides {% lorem %} tag, but why it doesn't provide {%
> > thumbnail %} tag?
>
> > Thumbnails are very common pattern.
>
> > Maybe this application (easy_thumbnails) is not the best choice, but
> > the general idea of having good and popular reusable thumbnail
> > solution distributed with django is very attractive to me.
>
> > On Fri, Sep 17, 2010 at 12:35 AM, Justin Lilly <jus...@justinlilly.com> wrote:
> >> One of the criteria for django.contrib is that the item for inclusion
> >> is a "de facto standard implementation of common patterns"[0]. From
> >> your own admittance there are conflicting views about how this should
> >> be handled. Perhaps if someone abstracts this out a bit and has
> >> something like image processing backends, it may make a bit more sense
> >> for inclusion, but as it stands, I'm -1.
>
> >> -justin
>
> >> [0]:http://jacobian.org/writing/what-is-django-contrib/
>
> >> On Thu, Sep 16, 2010 at 1:26 PM, ptone <pres...@ptone.com> wrote:
>
> >>> On Sep 16, 9:43 am, Patrick Altman <palt...@gmail.com> wrote:
> >>>> Another "community voice" contribution on this thread...
>
> >>>> I am of the opposite opinion. I think it would be better for Django as a whole if django.contrib approached zero. In fact, I would have no problem with seeing it go away completely and promote auth and sessions to core but done in a way that is pluggable. The reasoning behind this opinion is that it leaves the surface area in the project smaller to maintain and it's really not that hard to add a sorl-thumbnail external app to a Django project. Furthermore, it provides more freedom for these apps to mature and develop at their own pace.
>
> >>>> I realize I could very well be in a minority opinion here, but thought I'd throw it into the mix nonetheless.
>
> >>> Another vote for evolving away from contrib.
>
> >>> My hope is that one dayhttp://djangopackages.com/will become
>
> >>> On Sep 16, 9:43 am, Patrick Altman <palt...@gmail.com> wrote:
> >>>> Another "community voice" contribution on this thread...
>
> >>>> I am of the opposite opinion. I think it would be better for Django as a whole if django.contrib approached zero. In fact, I would have no problem with seeing it go away completely and promote auth and sessions to core but done in a way that is pluggable. The reasoning behind this opinion is that it leaves the surface area in the project smaller to maintain and it's really not that hard to add a sorl-thumbnail external app to a Django project. Furthermore, it provides more freedom for these apps to mature and develop at their own pace.
>
> >>>> I realize I could very well be in a minority opinion here, but thought I'd throw it into the mix nonetheless.
>
> >>> Another vote for evolving away from contrib.
>
hcarvalhoalves
Sep 17, 2010, 12:15:46 AM9/17/10
to Django developers
Although thumbnails are something *many* sites do, everyone have
wildly different requirements, and therefore, different solutions. Two
simple requirements that vary so much that makes impossible to have a
"standard" for thumbnails:
- The API for making thumbnails. Is it a backend class? Is it a
template tag? Is it a specially crafted URL with GET params, or maybe
REST?
- The storage for the thumbnails. Local files? S3 storage? Rackspace
Cloud Files? Maybe a cache backend? Something weird? And how to
invalidate cache images? Clean the cache if the original is gone?
As such, IMO is too hard to ship something so big and so opinionated
as a thumbnails solution on contrib. It's also so decoupled from
Django internals (it should depend just on a File object, and maybe
provide template tags) that it can live as a separate module just
fine.
Please consider Django aim is to be a framework, not a generic turn-
key solution for making sites (although it's easy to get started).
On Sep 16, 2:00 am, Yo-Yo Ma <baxterstock...@gmail.com> wrote:
> Is there any plans to incorporatehttp://github.com/SmileyChris/easy-thumbnails/
wildly different requirements, and therefore, different solutions. Two
simple requirements that vary so much that makes impossible to have a
"standard" for thumbnails:
- The API for making thumbnails. Is it a backend class? Is it a
template tag? Is it a specially crafted URL with GET params, or maybe
REST?
- The storage for the thumbnails. Local files? S3 storage? Rackspace
Cloud Files? Maybe a cache backend? Something weird? And how to
invalidate cache images? Clean the cache if the original is gone?
As such, IMO is too hard to ship something so big and so opinionated
as a thumbnails solution on contrib. It's also so decoupled from
Django internals (it should depend just on a File object, and maybe
provide template tags) that it can live as a separate module just
fine.
Please consider Django aim is to be a framework, not a generic turn-
key solution for making sites (although it's easy to get started).
On Sep 16, 2:00 am, Yo-Yo Ma <baxterstock...@gmail.com> wrote:
> Is there any plans to incorporatehttp://github.com/SmileyChris/easy-thumbnails/
Reply all
Reply to author
Forward
0 new messages