-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add more flexibility in URLs for MentionableMixin models #28
Comments
Wow, you are on fire :) 🔥 🔥 Having it as a method on the mixin is a much better idea than mine too, very good. Thank you. I shall give this a whirl tomorrow. |
Thanks for the suggestion - it was silly to have it require a unique slug in the first place, this makes it much more flexible. I had a look at your repo and used a simplified version of your models and urlpatterns to test against so hopefully it's good to go! |
Just wanted to let you know that I've got the basics working and have it live on my site now, quietly! Thank you so much for your assistance. I just need to work out how best to make it visible to people on my site now which is my own problem :) One odd thing I noticed with my
1 & 2 seem correct. |
A difficulty I've found integrating this into my existing site is with the requirement for the URL pattern for a
MentionableMixin
model to just have aslug
.I've added
MentionableMixin
to myPost
model, but the URL pattern for itsget_absolute_url()
/ detail view is like:"<slug:blog_slug>/<int:year>/<int:month>/<int:day>/<slug:post_slug>/"
I could change
post_slug
to be justslug
but thePost.slug
field has aunique_for_date
constraint on it, and there are manyPosts
with identical slugs, but with different dates. So theget_model_for_url_path()
wouldn't be able to find aPost
solely by using theslug
field.My first thought at a solution to this would be to add an optional setting to replace the
get_model_for_url_path()
function, something like this (as a default):I'm not sure that's the best name, or that it's the best idea, but still.
It would allow the replacement of that function with another that would receive a URL and optional
ResolverMatch
and either return the found model or else raise one ofBadConfig
orTargetDoesNotExist
exceptions. It would give flexibility over exactly how that model should be found. Is that enough flexibility? Is it a bit too complicated to describe how to replace the function? Will this all end in tears?As ever, I'm open to other, better ideas.
The text was updated successfully, but these errors were encountered: