empty stirrup
Hi,
I want to replace these classes with one that allows for recursive definitions in my project. However, I am having a very hard time understanding the code itself -- mostly that I don't know what methods, for example, are required to be implemented, what isn't, etc. Is there any clear information about this?
Thanks.
wise lava
"rekursive definitions"? Of url patterns?
empty stirrup
@wise lava precisely. The best I understand about URLResolver right now is that it “_populate(…)”s all paths assuming that the URL paths can be described as a directed acyclic graph, which means that the lack of cycles implies no recursion.
I can’t have a path that has a sub path that can then have a sub path that is the first path.
wise lava
... Can you give an example?
empty stirrup
A parent resource which has a child resource that can have as a child an instance of a parent resource, which can have an instance of a child resource, etc
No limit to how far down, theoretically. There is a way you can solve it by actually limiting it, but I prefer implementing proper recursion myself as it is cleaner to understand.
It would be less hacky to write a URLResolver that does this natively.
wise lava
i mean ... can you show an example as a url ?
empty stirrup
/computation/1/operation/computation/10/operation/computation/4/operation where “computation” takes an “operation”, and operations can use other computations as inputs
Computation is one-to-one with an operation
Well, computation takes one operation, but an operation can take multiple computations. Regardless, it’s a recursive relationship which would use the same view for the first computation as for the third
The point here is that URLResolver pre-populates all possible paths, which means that the depth must be pre-determined and basically hard coded. For a URL tree with two branches at each node, ten levels down, for example, would be ~2^10 = 1024 hardcoded separate URLs
*separate URL patterns
empty stirrup
I really would just like to know where, if anywhere, I can find documentation regarding implementing the URLResolver “interface”, so to speak. The code alone isn’t clear enough.
Such as, is namespace_dict necessary? app_dict? What’s needed to interoperate with a standard URLResolver?
What is the minimum I need for it to pass system checks?
magic summit
Seems to me it'd be far simpler to accept any URL and do the regex/split on slash in the view
empty stirrup
This doesn’t answer the question
This thread wasn’t about alternatives, it was about documentation
I’ve thought of all these alternatives already, it’s not really what I want.
magic summit
Thinking about it from the view's perspective, how are you envisaging the recursive path variables to be passed to the view as arguments?
empty stirrup
One way to do it would be to have it passed as *args, which can be used to generate the object’s composite primary key. I’m aware you can simulate this using your method, but you lose the niceties of being able to reverse(…), etc.
My guess is that composites make more sense when it comes to an object’s primary key validation on gets, puts, deletes
But passing *args knowing the order of them would also allow you to validate each parent
Basically a custom URLResolver would allow someone to more easily adhere to REST
At least in this recursive scenario
magic summit
Okay, now think about how the "easy" solution doesn't work with reverse. How do you envisage using reverse anyway? What do you want to pass it?
For your original example of /computation/1/operation/computation/10/operation/computation/4/operation, for example
empty stirrup
Please just be specific about what you think the issue is. Or please point me towards documentation about URLResolver. Thanks.
I don’t know what is possible, at least for my use case, until I understand the inner workings of that class. I’ve taken a look at the other solutions and they feel like it will cause more headaches for me in the end.
magic summit
All I can point you to is the code. You're trying to make Django's URL resolver do something it's not designed to do. It's designed to run down a predeterremined list of regular expressions, matching them against the URL, and calling views with args/kwargs based on capture groups in those regexes. There isn't anything in there to recurse, and I'm not even sure how to begin defining what it is you're asking for
empty stirrup
_reverse_with_prefix and resolve can be made recursive. I’d ignore calling _populate. This would likely mean that I need to convert all calls to re_path in my project to my custom one, but that’s fine. I’m aware that there may be performance issues, but currently that isn’t an concern; my hierarchy isn’t large except for the app that requires the recursion (recursion can blow up sometimes, obviously) but there isn’t an alternative if I’d like to stick to the Django semantics of paths being solely contained in urls.py files.
I can have a generator enumerate paths up to a certain depth, but then I run into the naming issues that I think you were alluding to. My URLResolver may be able to sidestep that issue in the code of _reverse_with_prefix, maybe under some constraints, but acceptable ones for me.
My issue is that I don’t know what other code in Django depends on features in URLResolver that are fundamentally incompatible with my idea, which is why I wanted documentation on it; the code isn’t clear enough, for me at least, to be confident about understanding it.
I think admin is one app that may have an issue, but I honestly just can’t tell.