Page MenuHomeSoftware Heritage

browse: provide search routes for GET arg handling
ClosedPublic

Authored by jbertran on Aug 25 2016, 3:44 PM.

Details

Summary

The routes we currently have that /could/ serve for
revision/content/origin search cannot be generated on the fly in a
Jinja2 template.

These new routes simply adequately redirect standard GET requests with
args to our own custom routes.

Diff Detail

Repository
rDWAPPS Web applications
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

jbertran retitled this revision from to browse: provide search routes for GET arg handling.
jbertran updated this object.
jbertran edited the test plan for this revision. (Show Details)
jbertran edited edge metadata.

Stray stash caused test failure ><

jbertran edited edge metadata.

templates: update to reflect search fn name change

I'm uneasy with that diff.
The way i understand it, you are doing the dispatch yourself.
But, it's @app.route decorator's job.

What do you think about adding the @app.route directly in the existing routes?

For example, your search_origin function is equivalent as the current browse_origin function.
So, adding directly those 2 new @app.route should already do what you want without any redirection.

@app.route('/origin/search/<string:origin_type>/url/<path:origin_url>/')
@app.route('/origin/search/int:origin_id>/')
@app.route('/browse/origin/<string:origin_type>/url/<path:origin_url>/')
@app.route('/browse/origin/<int:origin_id>/')
def browse_origin(origin_id=None, origin_type=None, origin_url=None):

@olasd if you have some thought about it, i'd gladly hear it.

Cheers,

In D111#2716, @ardumont wrote:

I'm uneasy with that diff.
The way i understand it, you are doing the dispatch yourself.
But, it's @app.route decorator's job.

@app.route doesn't handle GET parameters, you need to do that in the view. @app.route only handles URI fragments.

@jbertran is doing this because fragmented URIs are pretty, but building them in HTML forms involves a load of javascript that we can avoid with just a few redirects. I think the tradeoff is acceptable.

My issue is a bootstrapping one.

I want to generate the URLs that the forms use in the home.html Jinja2 template dynamically, so there's no magical 'archive.softwareheritage.org' value floating aroung.

The issue with this is that I can't use one of our regular flask-type routes like /something/<type:var>/blah/ with url_for for this, as this would require obtaining the values of the arguments for the route before the user has even seen the route (since these url_for calls go directly in the templates).

My fallback for this is to use standard GET-params routes like /something/?arg=value&stuff=blah for this, so I can still use url_for to generate my routes. This means I need to have logic to interpret the GET args, which I'd rather have it separate from the actual display function.

ardumont added a reviewer: ardumont.

@olasd @jbertran Thanks for the explanation ^^

This revision is now accepted and ready to land.Aug 29 2016, 7:49 PM
This revision was automatically updated to reflect the committed changes.