Django

i'm completely new to the django eco system, coming from flask.

what i want (and don't know how to accomplish) is to put some restrictions to a set of urls: x/<uuid>/images x/<uuid>/imageupload and others should only work, if uuid can be found in the database and is still valid.

in flask i would probably use a blueprint, but this concept does not seem to exist in django, right?

what i like about the blueprint concept is, that it's not possible to add a url under the x/<uuid> "namespace" and forgetting about the auth mechanism, as this is handled for all urls in the blueprint.

how would you handle this in django?

i've already learned about apps and a custom middleware, but this looks quite complicated on first sight? as the middleware always intercepts all requests, and i would have to check on my own if this is a request to x/<uuid>?

i've also looked at existing apps, and django-rq uses the statt_member_required decorator for each view. i will probably build something like that, but i would be more confident if i could apply this to the whole app, instead of having to decorate each function.

via https://indieweb.social/@adamghill/114115517598594251

via https://mastodon.social/@openrisk/114103439082745531

via https://hachyderm.io/@kevinrenskers/114072304000264553

via https://fosstodon.org/@laymonage/114014338677264240

via https://django-news.com/issues/272

For those who have been following or been involved with recent development of Ninja, you’ll notice that for about a year, almost all development has come to a halt. About 50 PRs have built up on the GitHub repository, many of which fix crucial issues, but are not getting any feedback and have no path forward to getting them merged. PRs that fix documentation will get merged in a day, but most PRs that touch code are left out to dry. Among these PRs include performance improvements, the validation vs. serialization split, my own fix for aliases, and much more. It's getting desperate enough that people are posting monkeypatches in the PRs.

I have spoken with Ninja's maintainer a bit about the issue and I think it's mostly just a split in priorities between him and myself. That's totally reasonable and respectable, its his project. But as a user of the library, I can't really say that I feel supported by this direction, and I would assume from the many repeated requests for review from the PR submitters that most in the community aren’t too happy either. Most of these existing issues aren’t complete showstoppers, but they are annoying and frustrating to work with, especially if you are using the library at scale.

So I’m forking the library under the new name, Django Shinobi, here. https://github.com/pmdevita/django-shinobi. I plan to lead the library for the longterm future as my job currently depends on it. Docs are sort of up but still need the workflow ironed out, and PyPI will be up later.

There aren’t any current plans to hard fork. Ninja does still get some minor changes here and there, and I plan to pull them downstream when possible. We may drift from full compatibility over time, especially as some of the larger scale changes are made, but that will be gradual. I'm not looking to separate from Ninja as much as provide some kind of solution for its current problems.

Of course, my end goal is to merge this project back upstream with Ninja. I believe Ninja still has the same end goals as we do, so it really makes the most sense to have one library. But, I think it’s clear that one library isn’t working right now, and a fork is necessary if we want to see things get fixed.

For now, if you have any PRs currently to Ninja that you want merged, or wanted to open any PRs but were discouraged from doing so, please open a PR to Shinobi! I'm also going to be starting another discussion for the project's roadmap so jump in there if you'd like to add your interest for a feature or fix, or suggest another.

I'd like to also recruit a few more core maintainers to help get eyes on things and make decisions, so reach out if that's something your interested in.

via https://mastodon.social/@python_discussions/113945835385715022

also check: The Key Benefits of Using a NoSQL Database in Django Development via Django News
and Official Django MongoDB Backend - Jib Adegunloye | Django Chat

via https://django-news.com/issues/270

via https://hachyderm.io/@kevinrenskers/113883446564707203

via https://fosstodon.org/@gagliardi_vale/113879003550726821

via https://indieweb.social/@adamghill/113861355667756794

via https://indieweb.social/@Fingel/113795139318331205

via https://fosstodon.org/@adamchainz/113798823996516983

via https://fosstodon.org/@carlton/113798310641582715

via https://fosstodon.org/@CodenameTim/113754056108765095

via https://social.joshthomas.dev/@josh/113715088603425286

via https://fosstodon.org/@adamchainz/113725658117070340