Hi Jacob,
I understand your points. Sorry if my initial post was not properly
fitted.
Thanks for taking the time to clarify this points.
I was maybe not clear enough or got lost in translation in my post/
ticket/pr.
but I tried to specify my intention in all of them:
"I'm personally not convince my implementation is the right one but I
hope
that could open the discussion to have a more extensible routing in
Django."
About 1. I'm aware that Django has a specific way of doing thing and
I'm sorry if it has been understood in the
way that Framework x does that or look better. Not my intention to
start a debat X better than Y ... it's just a tool at end of day.
I try to have a rational approach so I checked how people was already
solving this problem.
I was more referring to them as a doc reference because predicate is
not an easy concept to understand.
Personally, I wanted to open a discussion and I got it so I'm fine and
happy with any resulting solution.
Agreed that predicate is maybe (probably) not a way to go for Django.
But I tried initially to do that as a third party and I couldn't find
a way to
figure it out with having access to the request.
But probably because of my lack of understanding about how the url
routing works.
Based on the point 3 ?
Could we imagine being able to swapping via a settings the class used
for the UrlResolving Process.
For people being able to build their own in the same spirit of the
backends.
I'm glad to read "it should be
easier to add these sorts of things if you choose *without* needing to
add something new to Django."
Because that was my initial intention to offer a easy way to extend
the routing without
any understanding of how the url resolving process works.
Let me try an other approach to my proposition:
==
Problem: The RegexURLResolver is too complex and monolithic for
people understanding or extending it. It comes with some issues:
It don't allow to be swapped (from what I'm aware) or don't provide
any hooks to help people to extend the logic.
Solution : ** Something **
My Solution : Predicates
To not come empty handed, I propose a solution based on the concept of
predicate that I have seen in other framework (sorry for that).
Why I'm bringing that from somewhere else. Because I was lazy and
didn't want to invent a new concept when this one was heavily
documented already.
Is predicate solve the problem?
---
Yes but probably create others as @Sean highlighted. Touching the
RegexURLResolver is complex but writing a test function is easy.
signin = lambda r : 'signin' in r.POST
signup = lambda r : 'signup' in r.POST
Opinion:
I'm not convince that predicate is the right implementation for django
and I'm sure that the core dev will come with a much better idea to
this current problem.
===End
Thanks @Jacob @Sean for taking the time to answer me and giving
feedbacks.
I'll check how did with https://github.com/jacobian/django-multiurl
and try to can come with
a 3rd party solution.
On May 23, 4:22 am, Jacob Kaplan-Moss wrote:
> Hi Rach --
>
> Thanks for the clarification. I'd like to make three broader points.
> They may not seem like they're directly addressing your proposal, but
> stick with me, I promise this comes together to your specific proposal
> at the end:
>
> 1. "But framework X does it like this" isn't a particularly good
> argument for why *Django* should do something. Yes, it's important to
> understand and follow what's going on in the greater web world, and
> yes it's important to beg, borrow, and steal good ideas. But you have
> to articulate why an idea is *good for Django*. After all, if we
> wanted to be just like Framework X, we'd all just be using Framework
> X. In many ways the high quality of our competitors actually frees us
> up to be *more* skeptical of what we add to Django. We don't *need* to
> be more like other frameworks because those other frameworks are
> usually *great* -- if you like them, you should use them! We should be
> focusing on doing the things we're good at. Let Django be Django.
>
> 2. One of the really high bars you have to clear when you propose new
> things for Django is the bar of utility. It's not good enough to
> demonstrate that something's a good idea. It's not good enough to
> demonstrate that it solves your problem. It's not even good enough to
> demonstrate that it solves some bigger problem. You have to
> demonstrate that what you're proposing is so useful that a sizable
> portion of people using Django would be excited by your new thing. One
> of Django's real strengths is its stability, but the cost of that
> strength is that we say "no" a lot.
>
> 3. Flexibility is a very important goal. Our philosophy of "sensible
> defaults" doesn't mean that the default choice should be the only
> choice! It means that we should provide a reasonable default for most
> people, but then give
