Make endpoint optional in @route

[danjac]

Make endpoint an option in the @route decorator. By default it would still use the function name. This would allow more flexibility in larger applications:

def route(self, rule, **options):
    def decorator(f):
        endpoint = options.pop('endpoint', f.__name__)
        self.add_url_rule(rule, endpoint, **options)
        return f
    return decorator

[mitsuhiko]

I'm currently playing with the idea to add a module object for largish applications:

admin = app.module('admin', url_prefix='/admin')

@admin.route('/login')
def login():
    return 'Blafsel'

And then url_for('admin.index') returns the URL to the admin and the @admin.route decorated functions are prefixed with what is set as url_prefix.

[cgrinds]

I like this - similar to what I was doing with my routes changes but much better.

[mitsuhiko]

I did sketch something up in a branch: http://github.com/mitsuhiko/flask/tree/module-support

That does something similar to what is mentioned above. Check out the test for an idea how it works. Because it totally breaks compat with 1.0 i have not updated anything yet.

I am totally for breaking support with 0.1 but in order to keep the docs easy to understand there should not be "versionchanged" things all over the place. Have to think about something for the docs.

[cgrinds]

Not sure where I posted this the first time...

http://github.com/cgrinds/flask/tree/module-work

I don't accumulate the module routes, I just add them directly, which makes the code simpler.
I do this by not creating a module directly but asking the app for one. Instead of:
admin = flask.Module('admin', url_prefix='/admin')
admin = app.register_module('admin') # the url_prefix defaults to /name

other than that, it's all the same

[mitsuhiko]

I did that first, but the problem is that that way you can't have fully pluggable applications. What my code does currently is postponing that so that you can do "from someapplication import the_module" and then register it with your app.

[cgrinds]

That makes sense, I wasn't thinking of the interface or test as "from someapplication import the_module". The later the binding, the better, especially on GAE otherwise startup will kill ya.

So your design allows modules to be completely self-contained - flask reaches inside of the module and pulls out the routes. With my design there is no way to pass the app to the module when it's imported.

[danjac]

I've had a chance to play with the module-support branch. It's very intuitive, and as mitsuhiko points out allows you to create plugins quite easily - just expose the views as a Module instance and import the module when you are building the app. It gets around the circular import issue with the current version of Flask.

What are the plans to merge module-support into the main branch ? Do you envision further changes ?

[mitsuhiko]

What are the plans to merge module-support into the main branch ? Do you envision further changes ?

Not sure yet, I'm thinking about how far I want to go with that. Still playing around.

[mitsuhiko]

I did some more changes. Check out the module branch and build the docs and look at the api.rst for some ideas how that works.

[mitsuhiko]

I think I will close that as wontfix. If anyone wants to play around with that idea, consider creating a snippet for it and we can then move it into core if it proves to be useful and flexible enough.