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.
Differential D111
browse: provide search routes for GET arg handling jbertran on Aug 25 2016, 3:44 PM. Authored by
Details
The routes we currently have that /could/ serve for These new routes simply adequately redirect standard GET requests with
Diff Detail
Event TimelineComment Actions I'm uneasy with that diff. 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. @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, Comment Actions @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. Comment Actions 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. |