convore.json/groups/django-community/route-decorators/messages.json

[{"user_id": 275, "stars": [], "topic_id": 9084, "date_created": 1298650954.48403, "message": "Anyone ever try something like that with Django? Or is it simply not possible.", "group_id": 81, "id": 209192}, {"user_id": 275, "stars": [], "topic_id": 9084, "date_created": 1298650974.1376009, "message": "http://flask.pocoo.org/docs/quickstart/#routing", "group_id": 81, "id": 209198}, {"user_id": 13351, "stars": [], "topic_id": 9084, "date_created": 1298651942.053071, "message": "I think it isn't hard to add support of @app.route or any other decorator to the Django views, but main question for me is why. Django made url settings just in other way and imo it's good for Django", "group_id": 81, "id": 209400}, {"user_id": 275, "stars": [], "topic_id": 9084, "date_created": 1298650929.031569, "message": "I was just reading the intro to Flask, and noticed that they do something really nice: routes are defined with the handler for that route by using a decorator: @app.route('/')", "group_id": 81, "id": 209183}, {"user_id": 15284, "stars": [], "topic_id": 9084, "date_created": 1298651403.0901561, "message": "I love this Flask feature... I'm sure that there must be a way to do this on django, maybe with a new url router?", "group_id": 81, "id": 209330}, {"user_id": 13912, "stars": [], "topic_id": 9084, "date_created": 1298652993.6125109, "message": "Yeah, urls.py serves much better for larger projects. If you have up to 5-6 handlers flask's approach is pretty convenient. If you want to organize your urls like rails or pylons do by default and avoid having to edit urls.py all the time you can set up something similar to what the admin site does.", "group_id": 81, "id": 209572}, {"user_id": 13912, "stars": [], "topic_id": 9084, "date_created": 1298652681.2912979, "message": "Yes it can be done. You can make an App class for that purpose and wire it's app instance in the urlconf then you could use it to decorate views like that. The AdminSite class does interesting tricks with urlconfs if you're looking for an idea on how to implement it.", "group_id": 81, "id": 209522}, {"user_id": 2588, "stars": [{"date_created": 1298664101.2871721, "user_id": 9650}, {"date_created": 1298796007.9646249, "user_id": 4858}], "topic_id": 9084, "date_created": 1298652710.177598, "message": "One thing I really like about the way you specify routes in Django is that the urls.py files collectively provide a sort of table of contents for your site. Given a URL, one can quickly figure out which view function serves it, even if you're unfamiliar with the project source.", "group_id": 81, "id": 209530}, {"user_id": 3580, "stars": [{"date_created": 1298652812.5122459, "user_id": 2588}, {"date_created": 1298652849.975647, "user_id": 214}, {"date_created": 1298654410.1041379, "user_id": 1506}, {"date_created": 1298661528.6476469, "user_id": 56}, {"date_created": 1298790562.7485411, "user_id": 141}, {"date_created": 1298796041.3996551, "user_id": 4858}], "topic_id": 9084, "date_created": 1298652776.1635511, "message": "I did extensive stuff using homegrown containers and Bottle (both of which were route-decorator based) before Django. I really liked it initially, and it's great for small projects.. but once my apps grew large enough, I wasn't really excited about grepping to find URL patterns instead of having them organized nicely in one place.. Also, it made repeating method names an awkwardly common mistake (Bottle, and probably Flask allows you to get away with this without a problem).", "group_id": 81, "id": 209544}, {"user_id": 275, "stars": [], "topic_id": 9084, "date_created": 1298654233.823977, "message": "i can see the points about route-decorators not really scaling; url conf also gives you the ability to group routes with apps, etc.", "group_id": 81, "id": 209736}, {"user_id": 214, "stars": [{"date_created": 1298653289.9673719, "user_id": 2588}, {"date_created": 1298778198.509433, "user_id": 12002}], "topic_id": 9084, "date_created": 1298652934.6210899, "message": "I'm also less-than-excited about route decorators because they turn import-time side-effects into a core framework feature. Import-time side effects already cause most of the problems that are hardest to debug in Django; I'd like to reduce them, not introduce more.", "group_id": 81, "id": 209560}, {"user_id": 2588, "stars": [], "topic_id": 9084, "date_created": 1298653227.9113359, "message": "I agree - the conveniences in Flask make it an ideal choice if you know ahead of time that you're only going to be supporting a few endpoints.", "group_id": 81, "id": 209593}, {"user_id": 3580, "stars": [], "topic_id": 9084, "date_created": 1298654328.8421071, "message": "@steveivy yeah.. it's pretty handy as the project sprawls.. but we kinda off-topic'd you.. it certainly can be done, and if it's something you want to do go for it! It's not the end of the world to switch to urls.py if you find things getting hairy.", "group_id": 81, "id": 209759}, {"user_id": 275, "stars": [], "topic_id": 9084, "date_created": 1298661752.4082689, "message": "@simonw might be nice if django supported both, or, route decorators as an option", "group_id": 81, "id": 210622}, {"user_id": 56, "stars": [], "topic_id": 9084, "date_created": 1298661629.186621, "message": "route decorators happen to fit in to that model - personally I like them for small (4 or 5 view) projects and dislike them for larger apps, for the reasons discussed above", "group_id": 81, "id": 210583}, {"user_id": 56, "stars": [], "topic_id": 9084, "date_created": 1298661564.7858291, "message": "I hate how hard it is to figure out where signal registrations, admin.register etc style code is meant to go", "group_id": 81, "id": 210557}, {"user_id": 56, "stars": [], "topic_id": 9084, "date_created": 1298661852.545043, "message": "there's a bunch of interesting stuff that could be done to make urls.py etc a bit more flexible - many of my current projects end up with nasty hacks around that stuff", "group_id": 81, "id": 210635}, {"user_id": 275, "stars": [], "topic_id": 9084, "date_created": 1298659239.03161, "message": "oh, i didn't think it was off-topic: I was more curious about folks' thoughts on the idea of route decorators than necessarily making django use them.", "group_id": 81, "id": 210272}, {"user_id": 56, "stars": [], "topic_id": 9084, "date_created": 1298661550.799413, "message": "I actually think import-time side effects should be a core, documented part of Django", "group_id": 81, "id": 210552}, {"user_id": 56, "stars": [{"date_created": 1298778307.00211, "user_id": 12002}], "topic_id": 9084, "date_created": 1298661793.1338, "message": "maybe... but then new users would have to decide between the two, the docs would be more complex etc", "group_id": 81, "id": 210626}, {"user_id": 56, "stars": [], "topic_id": 9084, "date_created": 1298661813.6962941, "message": "I think I'd lean more towards making it super-easy to implement route decorators on top of Django - make it much easier to programatically maniuplate the routing table", "group_id": 81, "id": 210631}, {"user_id": 275, "stars": [], "topic_id": 9084, "date_created": 1298661804.0846009, "message": "true.", "group_id": 81, "id": 210628}, {"user_id": 275, "stars": [], "topic_id": 9084, "date_created": 1298661847.892601, "message": "right", "group_id": 81, "id": 210634}, {"user_id": 56, "stars": [{"date_created": 1298661656.543339, "user_id": 2588}, {"date_created": 1298893367.620142, "user_id": 978}], "topic_id": 9084, "date_created": 1298661590.2037179, "message": "I'd prefer it if my Django app was constructed at runtime in a predictable order, so I know exactly what gets imported / registered at what point", "group_id": 81, "id": 210571}, {"user_id": 56, "stars": [], "topic_id": 9084, "date_created": 1298661645.5615399, "message": "but if a django site was composed by executable code at runtime, rolling your own route decorators would be trivial", "group_id": 81, "id": 210585}, {"user_id": 56, "stars": [], "topic_id": 9084, "date_created": 1298661877.294874, "message": "I often want to do things like say \"is URL /blah/foo/ mapped in urls.py? Would it return a 404?\"", "group_id": 81, "id": 210639}, {"user_id": 56, "stars": [], "topic_id": 9084, "date_created": 1298661890.700376, "message": "that's not particularly clean at the moment", "group_id": 81, "id": 210640}, {"user_id": 214, "stars": [], "topic_id": 9084, "date_created": 1298663623.6712141, "message": "@simonw To the extent there are import-time side effects, yes they need to be more clearly documented and predictable. That's not an argument in favor of import-time side effects as a framework-building technique.", "group_id": 81, "id": 210909}, {"user_id": 214, "stars": [], "topic_id": 9084, "date_created": 1298663991.987365, "message": "Precisely (one of) the problem(s) with import-time side effects is that, by definition, they make \"predictable order\" impossible, because some rogue code can always go import something earlier than it was supposed to.", "group_id": 81, "id": 210943}, {"user_id": 214, "stars": [], "topic_id": 9084, "date_created": 1298663797.4940071, "message": "For instance, it would be better if there were a documented hook for startup-time preparation such as signal registration, rather than depending on it happening in module-level code as an import-time side effect.", "group_id": 81, "id": 210929}, {"user_id": 214, "stars": [], "topic_id": 9084, "date_created": 1298664159.4019589, "message": "Of course, \"rogue code\" in  Python can do whatever it wants - but accidentally importing something too soon is a particularly easy mistake to make, without malicious intent. Some Django apps (e.g. haystack) do that, and can cause mysterious circular imports as a result (and sometimes those circular imports only show up in production, not under runserver, because runserver does model validation and thus imports things in a different order).", "group_id": 81, "id": 210952}, {"user_id": 927, "stars": [{"date_created": 1298729824.9764559, "user_id": 2024}], "topic_id": 9084, "date_created": 1298664769.017447, "message": "I'm with @unbracketed and @carljm: this feature seems nifty for microapps but I like having urls.py on non-trivial projects, particularly since it means that my main urls.py can modify the values selected by an app author when it makes sense", "group_id": 81, "id": 211028}, {"user_id": 2024, "stars": [{"date_created": 1298778368.994689, "user_id": 12002}], "topic_id": 9084, "date_created": 1298730010.0693469, "message": "I'm throwing in with @acdha, @unbracketed, and @carljm too. Flask's routing is nifty for small apps, but even in medium sized apps I find it unwieldy and would prefer to keep my routing code separate from my view code. It just seems ugly to me to have everything all mixed together instead of separated out logically by function. Once you get to the point where it makes sense to split your Flask app out into multiple files I stop being particularly enamored with the routing decorators.", "group_id": 81, "id": 214325}]