librelist archives

Re: [flask] Improved Flask Module Support

From:

LeafStorm

Date:

2010-07-04 @ 19:23

So far, it looks pretty good. I have a few suggestions, though.

First, it would probably be a good idea to factor out the code from
_PackageBoundObject.send_static_file into a separate
serve_static_file(root_path, filename, **sendfile_opts) function. That
way, if an extension needed to send out extra files from some random
location (for example, an "uploads" extension), it could write its own
view to do so, and it would be relatively trivial. For example,

@uploads.register('/<filename>')
def uploaded_file(filename):
    return serve_static_file(current_app.config['UPLOADED_FILES_PATH'],
filename)

Second, since extensions are probably going to rely on custom modules
a lot to do things like serve their own static files and templates,
there should probably be some sort of naming convention for
extensions' modules. For example, if an extension "flaskext.jsstuff"
has a module with just support views (i.e. views that just generate
JavaScript or CSS or handle AJAX requests or something), static files,
and templates, the module's name should be '_jsstuff' and use the URL
prefix '/_jsstuff'.

Third, I can see a "themes" extension or something serving arbitrary
templates by deleting its module's 'jinja_loader' and replacing it
with a different one. It might be a good idea to document this
technique, and maybe give the module constructor a
'custom_template_loader' argument or something.

-- Regards, LeafStorm
"There are 10 types of people in the world - those who understand
binary and those who don't."

On Sun, Jul 4, 2010 at 8:28 AM, Armin Ronacher
<armin.ronacher@active-4.com> wrote:
> Hi,
>
> I spend a few hours now improving on the branch Justin Quick created
> earlier that broke Flask up into multiple modules inside a package.
>
> Based on his changes I was able to refactor a few Flask internals,
> mainly the way static files and templates are loaded.  I got rid of the
> SharedDataMiddleware for Flask and load static files with a regular view
> function now.  This allows us to have multiple static folders inside the
> modules.
>
> So for example an admin module can now have its own static files.  Not
> only static files, it's now also possible to load templates from
> template folders inside of modules.
>
> I am not totally happy with the implementation yet and will spend some
> more time refactoring there, but I think this is the step Flask should
> take next.  As such I will probably also stick with the approach of
> shipping a package instead of a single file.  Makes it a little easier
> to implement more complex things such as the new module support.
>
> However to avoid complicating the whole implementation I will write up a
> few guidelines about how Flask development is supposed to happen and
> some strict review guidelines.
>
> The changes are in the "module" branch in the official Flask repository
> on github.  The changes are not yet documented, but listed in the
> CHANGES file.  Also there are a few tests that show how it works.
>
> Let me know what you think about that and if the changes break your
> application.
>
>
> Regards,
> Armin
>

Hi,

On 7/4/10 9:23 PM, LeafStorm wrote:
> First, it would probably be a good idea to factor out the code from
> _PackageBoundObject.send_static_file into a separate
> serve_static_file(root_path, filename, **sendfile_opts) function.
Yes.  This is what I have in mind.  Which is why there is still some 
refactoring to do.

> Second, since extensions are probably going to rely on custom modules
> a lot to do things like serve their own static files and templates,
> there should probably be some sort of naming convention for
> extensions' modules. For example, if an extension "flaskext.jsstuff"
> has a module with just support views (i.e. views that just generate
> JavaScript or CSS or handle AJAX requests or something), static files,
> and templates, the module's name should be '_jsstuff' and use the URL
> prefix '/_jsstuff'.
Sounds like a very good idea.

> Third, I can see a "themes" extension or something serving arbitrary
> templates by deleting its module's 'jinja_loader' and replacing it
> with a different one. It might be a good idea to document this
> technique, and maybe give the module constructor a
> 'custom_template_loader' argument or something.
Right now the module's template loader is invoked by a proxying loader 
that prefix the template path with the module's template name.  I think 
there should be a way for a module to explicitly register it's template 
folder as "global" template folder.  So that an extension has the 
ability to provide a template outside of its realm similar to how a 
module can register an application wide before_request handler.


Regards,
Armin