Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to use Flask_Images with a document api endpoint? #31

Open
kramer65 opened this issue Mar 16, 2015 · 5 comments
Open

How to use Flask_Images with a document api endpoint? #31

kramer65 opened this issue Mar 16, 2015 · 5 comments

Comments

@kramer65
Copy link

I now have flask_images working flawlessly for static images with the following code:

{{ url_for('images', filename='have-a-nice-day.jpg', width=50) }}

I now want to use it for my dynamic document endpoint which gets images from a MongoDB instance. It is defined in Flask like this:

@app.route('/doc/<docId>')
def getDoc(docId):
    userDoc = UserDocument.objects(id=docId).first()
    if not userDoc:
        return abort(404)
    return Response(userDoc.file_.read(), mimetype=userDoc.file_.content_type)

So normally I create urls for an image using getDoc like this;

{{ url_for('getDoc', docId='8eb1796c-73b3-4398-855e-bfbfa02685d4') }}

How would I convert this to use flask_images for resizing? All tips are welcome!

@mikeboers
Copy link
Owner

I think you will be running into the same issue as #13, in that this project currently requires the images to actually exist on disk. There isn't an absolute requirement for that, so we've been throwing around the idea of abstracting the IO such that one could load/cache images anywhere.

@mikeboers
Copy link
Owner

It is quite inelegant, but Flask-Images may be able to make HTTP requests of itself for images. You could provide an endpoint that serves image data that is only accessible from localhost. It would end up downloading and caching a copy of every image (by default), and you would lose the cache-busting features.

Tell me more about your use case?

@kramer65
Copy link
Author

@mikeboers
My use case is that users can upload image files which I, for various reasons (scalability/security), save in a MongoDB instance. I need to keep the original image file data, but I guess 99% of the images that I'll be serving are thumbnails of the originals. For this reason I thought flask_images was perfect, but unfortunately this requirement that the file needs to exist on disk is quite inconvenient for me.

I guess what you're suggesting in your second post is to use the external option in core.build_url() to make a local http request. Is that correct?

I am now thinking it would be something like this:

{{ url_for('images', scheme='http', external='localhost', filename='doc/8eb1796c-73b3-4398-855e-bfbfa02685d4', format='png', width=100) }}

Would you have a suggestion of how I would be able to make that local http request?

And also: are you planning on implementing some of your IO-abstraction ideas in the near future or is that more of a long term plan? The website I'm building will probably be going live in about two months, so if this is something coming soon I would be happy to wait and maybe help out where I can so that I can use your (for the rest awesome!) plugin.. :-)

@mikeboers
Copy link
Owner

What I was suggesting would be a way to hack this system into working, but it would still result in a full copy of the image existing on disk (except that Flask-Images would manage it).

This IO abstraction isn't currently on my roadmap, as none of my current work comes near it. If your project enabled you to hire me to implement this, I could likely shift some things around to make it work.

@kramer65
Copy link
Author

@mikeboers
Mike, in the meantime I solved it myself using code I pasted in this gist: https://gist.github.com/kramer65/b1c93b5cc1ce023d070a

Your code and your suggestions in this thread have been a great inspiration though. Do you have a Bitcoin address where I can send you some beers?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants