Flask-Uploads 0.1 has just been released to PyPI. It provides support for uploading files and then serving said uploaded files. One of its most useful features is that you can set up a separate server to handle uploads and enable it in the config, but if you don't, it will serve the uploaded file itself (which is better than Django). PyPI http://pypi.python.org/Flask-Uploads/0.1 hg http://bitbucket.org/leafstorm/flask-uploads/ docs http://packages.python.org/Flask-Uploads Please let me know if there are any bugs (which there probably are). Anyway, coming soon (hopefully in the next couple of days) is another extension, Flask-Themes, which provides some infrastructure for themes. -- Regards, Matthew "LeafStorm" Frazier http://leafstorm.us/
This looks like a great idea, thanks. On 14 July 2010 00:29, LeafStorm <leafstormrush@gmail.com> wrote: > Flask-Uploads 0.1 has just been released to PyPI. It provides support > for uploading files and then serving said uploaded files. One of its > most useful features is that you can set up a separate server to handle > uploads and enable it in the config, but if you don't, it will serve the > uploaded file itself (which is better than Django). > > PyPI http://pypi.python.org/Flask-Uploads/0.1 > hg http://bitbucket.org/leafstorm/flask-uploads/ > docs http://packages.python.org/Flask-Uploads > > Please let me know if there are any bugs (which there probably are). > > Anyway, coming soon (hopefully in the next couple of days) is another > extension, Flask-Themes, which provides some infrastructure for themes. > -- > Regards, Matthew "LeafStorm" Frazier > http://leafstorm.us/ >
Hi, On 7/14/10 1:29 AM, LeafStorm wrote: > Flask-Uploads 0.1 has just been released to PyPI. It provides support > for uploading files and then serving said uploaded files. One of its > most useful features is that you can set up a separate server to handle > uploads and enable it in the config, but if you don't, it will serve the > uploaded file itself (which is better than Django). That is a brilliant extension. I like it a lot. I just don't like the patching of the request class, even if it's optional. Maybe we can find a better solution for Flask 0.6. That could be moved into the core Flask settings. Also, max_form_memory_size only limits what is uploaded into memory, if the thing swaps over to the filesystem the filesize is again unlimited. I would also set max_content_length. Regards, Armin
Hey,
On 7/14/10 10:31 AM, Armin Ronacher wrote:
> That could be moved into the core Flask settings.
Which just happened: http://bit.ly/bp6m3a
Regards,
Armin
Okay, Armin, could you take a look at the latest code and docs (http://bitbucket.org/leafstorm/flask-uploads/) and tell me what you think of the current solution? Because I'm still a bit confused about whether to keep patch_request_class as is and just deprecate it, or leave it in and add max_content_length, or switch it to just max_content_length, or what. -- Regards, Matthew "LeafStorm" Frazier http://leafstorm.us/
Hi, On 7/14/10 6:23 PM, LeafStorm wrote: > Okay, Armin, could you take a look at the latest code and docs > (http://bitbucket.org/leafstorm/flask-uploads/) and tell me what you > think of the current solution? Because I'm still a bit confused about > whether to keep patch_request_class as is and just deprecate it, or > leave it in and add max_content_length, or switch it to just > max_content_length, or what. I would deprecate patch_request_class when 0.6 is released and change the code to set max_content_length instead. Regards, Armin
On 07/14/2010 01:00 PM, Armin Ronacher wrote: > Hi, > > I would deprecate patch_request_class when 0.6 is released and change > the code to set max_content_length instead. > > > Regards, > Armin I did that, but I also set it so that if `None` was passed as the size, it would use the `MAX_CONTENT_LENGTH` setting, and not touch it if it was on Flask 0.6 or greater. Hopefully, that's the best way to handle it. Assuming no one finds any bugs, it's probably ready for a 0.1.1 release. (Note to self: Ask people to do code review before releasing extensions next time.) -- Regards, Matthew "LeafStorm" Frazier http://leafstorm.us/
You work too fast. (Not that that's a bad thing. When you compare Flask's speed of updating to some OSS projects, it's a good thing.) My motivation for patch_request_class was that it's the technique you demonstrated in the "File Uploads" pattern, and I didn't look at the Werkzeug source code clearly enough to realize that it was just for the memory and not for the content length in total. Ah well. You will probably want to update the file uploads docs to mention the new technique as opposed to patching the request class. At any rate, I guess my next course of action will be to release an 0.1.1 that deprecates patch_request_class and mentions the MAX_CONTENT_LENGTH setting in the docs, and fixes any bugs that I or other people find. (Also, I hate to keep asking you for logos - I need to learn how to make them myself - but a logo for this and one for Flask-Themes would be nice.) On 07/14/2010 04:50 AM, Armin Ronacher wrote: > Hey, > > On 7/14/10 10:31 AM, Armin Ronacher wrote: >> That could be moved into the core Flask settings. > Which just happened: http://bit.ly/bp6m3a > > > Regards, > Armin -- Regards, Matthew "LeafStorm" Frazier http://leafstorm.us/
What's the idea behind Flask-Themes ? Something like Deliverance ? On 14 July 2010 15:52, LeafStorm <leafstormrush@gmail.com> wrote: > You work too fast. (Not that that's a bad thing. When you compare > Flask's speed of updating to some OSS projects, it's a good thing.) > > My motivation for patch_request_class was that it's the technique you > demonstrated in the "File Uploads" pattern, and I didn't look at the > Werkzeug source code clearly enough to realize that it was just for the > memory and not for the content length in total. Ah well. You will > probably want to update the file uploads docs to mention the new > technique as opposed to patching the request class. > > At any rate, I guess my next course of action will be to release an > 0.1.1 that deprecates patch_request_class and mentions the > MAX_CONTENT_LENGTH setting in the docs, and fixes any bugs that I or > other people find. > > (Also, I hate to keep asking you for logos - I need to learn how to make > them myself - but a logo for this and one for Flask-Themes would be nice.) > > On 07/14/2010 04:50 AM, Armin Ronacher wrote: >> Hey, >> >> On 7/14/10 10:31 AM, Armin Ronacher wrote: >>> That could be moved into the core Flask settings. >> Which just happened: http://bit.ly/bp6m3a >> >> >> Regards, >> Armin > > -- > Regards, Matthew "LeafStorm" Frazier > http://leafstorm.us/ >
On 07/14/2010 10:54 AM, Dan Jacob wrote: > What's the idea behind Flask-Themes ? Something like Deliverance ? It provides theming infrastructure for applications. It's not quite on Bitbucket yet, so you can't see for yourself, but the basic concept is you have themes, which are basically just folders with an "info.json" file containing metadata, a "static" folder, and a "templates" folder. And when you call "setup_themes" on your application, it will: - Add a module (named _themes) that serves the themes' static files and templates for you. - Add some template globals for accessing the themes' templates and media (i.e. if you are in a template of the "default" theme, calling "theme('layout.html')" will return "_themes/default/layout.html", and something similar for theme_static). - Add a theme manager that loads the themes, using callables called theme loaders. And then you can call "render_theme_template" with the theme and template name you want, and it will render the template from within that theme, and the theme has access to all its templates and static files using the aforementioned template globals. Unlike Deliverance, it doesn't magically transform HTML. (Which looks confusing anyway.) It just switches out plain old Jinja2 templates. -- Regards, Matthew "LeafStorm" Frazier http://leafstorm.us/