[omaha] Static vs media files in django

[Steve Young]

Been traveling and just getting back to this.  Thanks for the ideas - looks
like I will need a separate app for image handling.  Back to the code!

Steve


On Wed, May 28, 2014 at 4:56 PM, Jeff Hinrichs - DM&T <jeffh at dundeemt.com>
wrote:

> Yes, just name the image file after the primary key for the record you
> created for it in the db.  Store the user supplied name in the db. i.e.
>
> \you\storage\for\user\images\1.jpg
>
> Image(pk=1, type='image/jpeg', uname='My Cute Kittens: the cuddlies.jpg',
> ...)
>
> after they upload, you'll need to qc the image and determine it's type,
> size (h x w), bytes
> then if it passes your tests, make a record, save the meta info about the
> image, move/rename the image to its final home.
>
> i.e.
> \quarantine\My\ Cute\ Kittens:\ the\ cuddlies.jpg   -> verify -> make
> record and save attributes -> then move the file to \approved\1.jpg
>
> Users are nice, Operating systems are a pain in the arse.  you'll see .jpg,
> .jpeg and stuff with no extension or a wrong extension.  That is why I
> would encourage you to never trust an user upload.  In the long run, even
> if you skip my advice, you'll end up implementing it bit by bit as you
> encounter problems.  It's bad enough dealing with users with good
> intentions, let alone malicious users.   quarantine -> verify -> approve
>
> You'll also encounter lots of duplicate names too.  (That alone is reason
> not to just blindly use the user supplied file name.)
>
> clear as mud?
>
>
>
> On Wed, May 28, 2014 at 4:14 PM, Steve Young <wereapwhatwesow at gmail.com
> >wrote:
>
> > *  * never use supplied names for file names*
> >
> > do you have an alternative for this?  I think I remember using Django's
> > file upload feature a while back and it gave a long un-descriptive name.
> >  The initial upload I will do of about 1000 images, then additional
> images
> > will be added by users and myself.
> >
> >
> > Steve
> >
> >
> > On Tue, May 27, 2014 at 6:25 PM, Jeff Hinrichs - DM&T <
> jeffh at dundeemt.com
> > >wrote:
> >
> > > How many images are you thinking?
> > > Some Generalizations:
> > >   * The fewer folders the better.
> > >   * never use supplied names for file names
> > >   * keep images out of a database unless the DB is designed for it
> > > specifically(most are not)
> > >   * your categories will fall woefully short, I'd recommend a
> folksonomy
> > > over a taxonomy - http://en.wikipedia.org/wiki/Folksonomy
> > >
> > > more specific but still incomplete:
> > >  * an image table
> > >  * each image file named by the _id of the instance
> > >  * store image type in the table
> > >  * store uploaded by
> > >  * store uploaded when
> > >  * a category/tag table
> > >  * an m-n relationship between image and category/tag (many to many)
> > >
> > >
> > > On Tue, May 27, 2014 at 6:00 PM, Steve Young <
> wereapwhatwesow at gmail.com
> > > >wrote:
> > >
> > > > Thanks.  How about organizing the files - eventually they will be
> > tagged
> > > to
> > > > make it simple for users to find images and add them to new cards.
> > >  Should
> > > > I put all the images in one folder or categorize them with
> sub-folders?
> > > > Or even put the images in a database?
> > > >
> > > > Steve
> > > >
> > > >
> > > > On Tue, May 27, 2014 at 3:38 PM, Jeff Hinrichs - DM&T <
> > > jeffh at dundeemt.com
> > > > >wrote:
> > > >
> > > > > If you don't not need to distinguish between the images you supply
> > and
> > > > user
> > > > > upload images then yes.
> > > > > caveat: If some subset of the images are not for cards but for the
> > site
> > > > in
> > > > > general, I'd put that subset in static.
> > > > >
> > > > >
> > > > > On Tue, May 27, 2014 at 9:37 AM, Steve Young <
> > > wereapwhatwesow at gmail.com
> > > > > >wrote:
> > > > >
> > > > > > Using Django 1.7 building a flashcard app.  Currently I have
> about
> > > 1000
> > > > > > images - one per card, and images can be used on multiple cards.
> > >  Later
> > > > > on
> > > > > > users may be able to upload images also.  Django seems to have 2
> > > basic
> > > > > ways
> > > > > > to serve static files - Static and Media.  From what I gather
> > static
> > > is
> > > > > for
> > > > > > css, logos, and other admin created files, and media is for user
> > > > uploaded
> > > > > > content.?
> > > > > >
> > > > > > I am thinking Media is the way to go?  If you have any other
> > > > suggestions
> > > > > on
> > > > > > handling images please chime in.
> > > > > >
> > > > > > Thanks.
> > > > > >
> > > > > > Steve
> > > > > > _______________________________________________
> > > > > > Omaha Python Users Group mailing list
> > > > > > Omaha at python.org
> > > > > > https://mail.python.org/mailman/listinfo/omaha
> > > > > > http://www.OmahaPython.org
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best,
> > > > >
> > > > > Jeff Hinrichs
> > > > > 402.218.1473
> > > > > _______________________________________________
> > > > > Omaha Python Users Group mailing list
> > > > > Omaha at python.org
> > > > > https://mail.python.org/mailman/listinfo/omaha
> > > > > http://www.OmahaPython.org
> > > > >
> > > > _______________________________________________
> > > > Omaha Python Users Group mailing list
> > > > Omaha at python.org
> > > > https://mail.python.org/mailman/listinfo/omaha
> > > > http://www.OmahaPython.org
> > > >
> > >
> > >
> > >
> > > --
> > > Best,
> > >
> > > Jeff Hinrichs
> > > 402.218.1473
> > > _______________________________________________
> > > Omaha Python Users Group mailing list
> > > Omaha at python.org
> > > https://mail.python.org/mailman/listinfo/omaha
> > > http://www.OmahaPython.org
> > >
> > _______________________________________________
> > Omaha Python Users Group mailing list
> > Omaha at python.org
> > https://mail.python.org/mailman/listinfo/omaha
> > http://www.OmahaPython.org
> >
>
>
>
> --
> Best,
>
> Jeff Hinrichs
> 402.218.1473
> _______________________________________________
> Omaha Python Users Group mailing list
> Omaha at python.org
> https://mail.python.org/mailman/listinfo/omaha
> http://www.OmahaPython.org
>