Thanks for introducing me to Masonite, it looks like it has a good API, and I especially like the matcher-style routing.
Would just like to offer a few minor corrections. Firstly, Django's ORM doesn't use the Data Mapper pattern as you described -- it also uses Active Record. In the Active Record pattern, your domain objects contain the logic that handle persistence and querying, which clearly describes Django's models (it even says so here: docs.djangoproject.com/en/2.2/misc...). Perhaps you're confusing Django's ORM with SQLAlchemy, which allows you to use the Data Mapper pattern.
Also, regarding middleware, your comparison between Masonite and Django code examples isn't exactly fair -- they're not doing comparable things, because the auth handling logic in Masonite is clearly done elsewhere, while you put everything in the Django's middleware example. In addition, that is really bad Django code.
In addition, Django's middleware API has also been updated recently -- the one true way to write middleware in Django is now just a function/callable. Here's how Django's middleware that is comparable to your Masonite middleware would look like, assuming it is ordered after the default auth middleware:
As for the Django middleware example, how do you only execute it before or after the request with this style? What would be an example of middleware executing after a request?
I'm not sure what you mean by "before" a request -- the whole request/response cycle is initiated by a request from the client, anything before that is outside the cycle.
There are hooks you can use for when the request has started (but hasn't finished), or after a http response has been sent to the client (docs.djangoproject.com/en/dev/ref/...), but I must say I've never used them. If I needed to be doing that, I'd be writing WSGI middleware instead, or using something like Celery/Django Channels to do a task asynchronously.
yeah been a while since I personally used Django. I think it was beginning of 1.11ish I believe. Just trying to see if there's something comparable to the Masonite middleware example above where its:
--> execute a "before" middleware (cleaning the request, setting some variables on some classes, redirecting for auth, etc)
--> execute the controller method (django view)
--> execute an "after" middleware (setting response headers, setting status code, converting controller method response (i.e dictionary to json converting) etc)
--> execute a "before" middleware (cleaning the request, setting some variables on some classes, redirecting for auth, etc)
You mean like this?
defglobal_auth_middleware(get_response):defmiddleware(request):ifnotrequest.user.is_authenticated:returnredirect('/login/')# before logic here
request.some_property=Property.objects.get(request['HTTP_X_PROPERTY_ID'])returnget_response(request)returnmiddleware
--> execute an "after" middleware (setting response headers, setting status code, converting controller method response (i.e dictionary to json converting) etc)
Could be something like this.
defglobal_auth_middleware(get_response):defmiddleware(request):ifnotrequest.user.is_authenticated:returnredirect('/login/')# 'after' logic here
response=get_response(request)response['X-Custom-Header']='somevalue'returnresponsereturnmiddleware
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for introducing me to Masonite, it looks like it has a good API, and I especially like the matcher-style routing.
Would just like to offer a few minor corrections. Firstly, Django's ORM doesn't use the Data Mapper pattern as you described -- it also uses Active Record. In the Active Record pattern, your domain objects contain the logic that handle persistence and querying, which clearly describes Django's models (it even says so here: docs.djangoproject.com/en/2.2/misc...). Perhaps you're confusing Django's ORM with SQLAlchemy, which allows you to use the Data Mapper pattern.
Also, regarding middleware, your comparison between Masonite and Django code examples isn't exactly fair -- they're not doing comparable things, because the auth handling logic in Masonite is clearly done elsewhere, while you put everything in the Django's middleware example. In addition, that is really bad Django code.
In addition, Django's middleware API has also been updated recently -- the one true way to write middleware in Django is now just a function/callable. Here's how Django's middleware that is comparable to your Masonite middleware would look like, assuming it is ordered after the default auth middleware:
So, clearly those two code samples you provided comparing Django and Masonite middleware do not do the comparison justice.
Masonite's fine-grained middleware control is a neat idea though.
Fair points. I'll update my post.
As for the Django middleware example, how do you only execute it before or after the request with this style? What would be an example of middleware executing after a request?
I'm not sure what you mean by "before" a request -- the whole request/response cycle is initiated by a request from the client, anything before that is outside the cycle.
There are hooks you can use for when the request has started (but hasn't finished), or after a http response has been sent to the client (docs.djangoproject.com/en/dev/ref/...), but I must say I've never used them. If I needed to be doing that, I'd be writing WSGI middleware instead, or using something like Celery/Django Channels to do a task asynchronously.
yeah been a while since I personally used Django. I think it was beginning of 1.11ish I believe. Just trying to see if there's something comparable to the Masonite middleware example above where its:
--> execute a "before" middleware (cleaning the request, setting some variables on some classes, redirecting for auth, etc)
--> execute the controller method (django view)
--> execute an "after" middleware (setting response headers, setting status code, converting controller method response (i.e dictionary to json converting) etc)
Thanks though!
Hmm, maybe I'm misunderstanding you, but:
--> execute a "before" middleware (cleaning the request, setting some variables on some classes, redirecting for auth, etc)
You mean like this?
Could be something like this.