I also prefer URLs all concentrated in a single place, instead of spread
out all over the codebase. The reason is that it is dead simple to track
which view is associated with a URL, just look at the ROOT_URLCONF file and
track the view following the patterns. If you have them spread out, you'll
ne
Am Donnerstag, 29. September 2016 20:42:47 UTC+2 schrieb Sjoerd Job Postmus:
>
> I have a feeling this is orthogonal to the original request.
>
> The original request/problem was "regex is hard".
> Your response answers/solves "the URL definition is somewhere different
> from the view definition
I have a feeling this is orthogonal to the original request.
The original request/problem was "regex is hard".
Your response answers/solves "the URL definition is somewhere different from the view definition".
Both issues are realistic [1], and orthogonal.
[1]: I myself have great aversion to the a
Hi Emil,
that's not only a teaching issue. Also experienced devs struggle with this
way to declaring URLs.
Internally, we developed a UrlMixin for our view classes such as:
class MyView(UrlMixin, View):
url_pattern = r'^bar/foo/$'
view_name = 'my-index'
# rest of view code
That'
Hi Emil,
that's not only a teaching issue. Also experience devs struggle with this
way to declaring URLs.
Internally, we developed a UrlMixin for our view classes such as:
class MyView(UrlMixin, View):
url_pattern = r'^bar/foo/$'
view_name = 'my-index'
# rest of view code
That's
Hi all,
I already solved the problem for hard urls writing/reading. Please take a
look, maybe you are interested in it :)
https://github.com/phpdude/django-macros-url
It provides simple & clear way to build your strong urls patterns.
Example from project page is attached
urlpatterns = patter
On Friday, 23 September 2016 07:53:49 UTC+1, Sjoerd Job Postmus wrote:
>
>
> I hope I did not offend you with my post on how the code turned out. That
> was not my intention, but if it did offend you: my apologies.
>
>
Don't worry, no offence taken :)
Cheers,
Alasdair
--
You received this mess
On Thursday, September 22, 2016 at 5:39:31 PM UTC+2, Alasdair Nicol wrote:
>
> On Thursday, 22 September 2016 15:59:12 UTC+1, Sjoerd Job Postmus wrote:
>>
>> Another part I see is that the high coupling between Django and the URL
>> resolvers (as mentioned in
>> http://sjoerdjob.com/post/is-djang
On Thursday, 22 September 2016 15:59:12 UTC+1, Sjoerd Job Postmus wrote:
>
> Another part I see is that the high coupling between Django and the URL
> resolvers (as mentioned in
> http://sjoerdjob.com/post/is-djangos-url-routing-tightly-coupled/ )
> should probably be cleaned up, if it is desire
I'll try and update my library over the next couple of days to also support
regex fragments and converters supporting parameters.
Another part I see is that the high coupling between Django and the URL
resolvers (as mentioned in
http://sjoerdjob.com/post/is-djangos-url-routing-tightly-coupled/
Wanted to add my support for this.
Personally I'd be totally in favour of considering something along these
lines for core, once there's a fully proven design.
The capture syntax is:
* Far simpler.
* Meets pretty much every single real-world case I ever see.
* Gives us type coercion.
* Also able
Impressive! Using it in a project right now, so much nicer for a
non-beginner like me too. No more regexs!
Looking forward to a Django patched that allows casting of the variables
too.
/Emil
On 2016-09-19 08:57, Sjoerd Job Postmus wrote:
Just wanted to announce the following: it's available
Hi,
Before I looked into the code, I found this really hard to believe. In my
mind, the whole resolving framework would be built upon classes providing
`resolve` and `reverse` methods. I was only partially right. I looked into
it a bit more and wrote up my conclusions
here: http://sjoerdjob.co
Just wanted to announce the following: it's available on pypi:
https://pypi.python.org/pypi/django-simple-url/0.0.2
Kind regards,
Sjoerd Job
On Thursday, September 15, 2016 at 9:03:21 AM UTC+2, Sjoerd Job Postmus
wrote:
>
> Hi :).
>
> Yes, I also added the other syntax yesterday evening, so the
I actually do have working code[1] that among other things abstracts the
regex to a Constraint, which allows you to easily inject your own custom
logic for resolving and reversing url fragments. This allows for a "simple"
system at a more fundamental level, rather than just translating the
"sim
On 2016-09-16 09:30, Curtis Maloney wrote:
On 15/09/16 16:37, Curtis Maloney wrote:
Somewhere I have code to provide a "parse" based URL router.
Will dig it up now 1.10 has has shipped
Ah, found it...
So, here is a gist of a sample of using parse
(https://pypi.org/project/parse/) instead of
I'd really, really like an alternate URL resolver which does typecasting. I
mean, if I'm specifying the type right there, why not expect the resolved
to be the type I just specified? In 995 of URLs, you're talking about three
basic types anyway: strings, integers, and (increasingly) UUIDs. After
In my opinion, there is two point. First, core django should allow
different url resolver. Second, these different url resolver should
start as third party package.
Without first point, people need to hack django if they want to
experiment new kind of resolver. Like one providing typecasting or a
On 15/09/16 16:37, Curtis Maloney wrote:
Somewhere I have code to provide a "parse" based URL router.
Will dig it up now 1.10 has has shipped
Ah, found it...
So, here is a gist of a sample of using parse
(https://pypi.org/project/parse/) instead of regex.
https://gist.github.com/funkybob/3
Fwiw, I spent a little time investigating this a couple of years ago. I
would like to see Django officially bless the idea of alternative URL
systems, and provide the "full" regex system and preferably at least one
"simple" system - even if all that system supports is integers and slugs.
This would
On Thursday, September 15, 2016 at 10:38:09 AM UTC+2, Michal Petrucha wrote:
>
>
> As cool as this idea sounds, I really don't think the URL dispatcher
> is a correct component to make database queries. FWIW, I've seen
> similar magic implemented in view decorators, and the thing I remember
>
On Thu, Sep 15, 2016 at 12:56:16AM -0700, Sjoerd Job Postmus wrote:
> I'm not sure if I agree.
>
> On the one hand I would like to say:
>
> "I agree. For instance, if the type is `hex`, it would be really weird if
> it were to be cast to an int. For `uuid`, would you expect a `UUID`
> instance,
On Thursday, September 15, 2016 at 8:28:07 AM UTC+2, Emil Stenström wrote:
>
> Tim Graham: Does this change your view that this should be done outside of
> core? Do you buy the argument that beginners are unlikely to install third
> party packages when learning django?
>
Imo it should still s
I'm not sure if I agree.
On the one hand I would like to say:
"I agree. For instance, if the type is `hex`, it would be really weird if
it were to be cast to an int. For `uuid`, would you expect a `UUID`
instance, or just a string?"
but alternatively, ...
"Wouldn't it be really cool if you co
In my opinion, it should remain a string. That's the behaviour it is now,
and it'll mean it can remain as a 3rd party package.
Perhaps to show it isn't being cast, it could be renamed to "integer",
which would avoid confusion
On 15 Sep 2016 8:03 a.m., "Sjoerd Job Postmus" wrote:
> Hi :).
>
> Ye
Hi :).
Yes, I also added the other syntax yesterday evening, so the
syntax is now fully supported. (But it does not yield an int!!).
Currently only `'int'` is registered as a valid type, with the regex
r'[0-9]+'. More can be registered using `django_simple_url.register('hex',
'[0-9a-fA-F]+')`
Somewhere I have code to provide a "parse" based URL router.
Will dig it up now 1.10 has has shipped
On 14 September 2016 6:38:20 PM AEST, Florian Apolloner
wrote:
>Hi Emil,
>
>On Tuesday, September 13, 2016 at 9:50:22 PM UTC+2, Emil Stenström
>wrote:
>>
>> and more experienced users are expect
On Tuesday, 13 September 2016 21:54:49 UTC+2, ludovic coues wrote:
>
> There is third party module providing third party url function. Surlex
> [1] have been mentionned. But any third party solution will need to
> provide function compatible with django.conf.urls.url.
> Line 64 of django/urls/
See Sjoerd's code in a later reply to this thread, let's start
experimenting there. /E
On Tuesday, 13 September 2016 22:17:34 UTC+2, Ares Ou wrote:
>
> Emil,
>
> Please count me in if you'd like to start a new DEP. I'm also
> very interested to take this new challenge. And maybe we
> should div
Great initiative!
I really think you should use the flask syntax instead of the rails one
that I first suggested. Seems this is the consensus from this thread, and
that makes it more likely to get it to core one day.
/Emil
On Wednesday, 14 September 2016 11:02:23 UTC+2, Sjoerd Job Postmus wro
Hi all,
Since it seemed like an interesting idea to me, I started development of a
third-party plugin.
It's currently at:
https://github.com/sjoerdjob/django-simple-url
Since I only started today, I have no readme/setup.py yet. Will come later
this week I hope.
Current usage is
from
Hi Emil,
On Tuesday, September 13, 2016 at 9:50:22 PM UTC+2, Emil Stenström wrote:
>
> and more experienced users are expected to switch over to using regexes
> directly to get the exact behavior they want.
>
How so? Personally I would use this quite quickly since a few builtin types
would cov
Emil,
Please count me in if you'd like to start a new DEP. I'm also
very interested to take this new challenge. And maybe we
should dive into the code of URL resolver part of Django before
we actually kick off?
Anyway, I myself as a experienced user also like this idea. But as
Tim and Ludovic men
There is third party module providing third party url function. Surlex
[1] have been mentionned. But any third party solution will need to
provide function compatible with django.conf.urls.url.
Line 64 of django/urls/revolvers.py is get_resolver. This function
return a RegexURLResolver, using is ar
One problem with this approach, to let the community decide on this type of
feature, is the target audience of it. This is mainly a feature for
beginners, and more experienced users are expected to switch over to using
regexes directly to get the exact behavior they want. Beginners likely
won't
I would like to see if this could be done as a third-party project (allow
"pluggable URLs" which could use any syntax). If not, then let's accept a
patch to Django to support it. Over time, if there's some strong consensus
about a particular third-party package, then we could bring it in to core
So it looks to me that the consensus is that this IS in fact a good idea,
to supply a simpler, regex-free method to define URL:s.
It also seems that the best liked version is something that's similar to
what flask uses: /articles///.
I've never written a DEP before, but it sounds like a fun ch
Hi,
Good to hear so much from you.
Just want know more, could anyone also explain why at first Django
chose to use regex instead of a simple URL routing, except for the
flexibility?
By the way, like you said, routing in flask (or should say Werkzeug?) is
also
converting the simple URLs into Rege
Hi,
I don't think that the 'including' URLs part forms a problem here.
For the given example, it should be easily doable
> from django.conf.urls import simple_url
> from . import views
> urlpatterns = [
> simple_url('articles/2003/', views.special_case_2003),
> simple_url('articles/:year
Hi Ares,
Your suggestion, used in urls.py would translate to:
from django.conf.urls import simple_url
from . import views
urlpatterns = [
simple_url('articles/2003/', views.special_case_2003),
simple_url('articles//', views.year_archive),
simple_url('articles///',
views.month_arch
This is actually an interesting concept, and wouldn't incur an, overheard
at runtime if simple_url translated in to full regex format at launch time
(or on first request, which is when the urls get loaded if I recall
correctly).
I don't think this would get in the way of includes, and if it's a
tr
This is actually an interesting concept, and wouldn't incur an overheard at
runtime if simple_url translated in to full regex format at launch time (or
on first request, which is when the urls get loaded if I recall correctly).
I don't think this would get in the way of includes, and if it's a
Tjena Emil,
On Mon, Sep 12, 2016 at 01:32:45PM -0700, Emil Stenström wrote:
> Hi Djangonauts,
>
> I'm just back from my second year of teaching Django to absolute beginners.
> The course is a combination of HTML, CSS, Python, and Django, and after
> five days of coding they have a real live web
Hi Emil,
There are projects like https://github.com/codysoyland/surlex which I like
very much. In the end, whatever you can come up which translates to regex
in the background would work just fine for django. I personally like what
werkzeug does -- "stealing" that sounds like an idea too :D I d
Hi,
Actually flask uses a style very similar to what you want.
To my knowing, you must use this pattern for Django because it has the
concept of *including *
URLs.
Routing in flask:
@app.route('post/', methods=['GET'])
def post_view(post_id=None):
# do something to render the post
retur
Hi Emil,
It is a very interesting idea.
+1 from me
On Mon, Sep 12, 2016 at 11:32 PM, Emil Stenström wrote:
> Hi Djangonauts,
>
> I'm just back from my second year of teaching Django to absolute
> beginners. The course is a combination of HTML, CSS, Python, and Django,
> and after five days of
Hi Djangonauts,
I'm just back from my second year of teaching Django to absolute beginners.
The course is a combination of HTML, CSS, Python, and Django, and after
five days of coding they have a real live website that they can show to
friends. It's always such a great experience to see the loo
47 matches
Mail list logo