re: 5 reasons why people are choosing Masonite over Django VIEW POST

FULL DISCUSSION
 

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:

def global_auth_middleware(get_response):
    def middleware(request):
        if not request.user.is_authenticated:
            return redirect('/login/')
        return get_response(request)
    return 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?

def global_auth_middleware(get_response):
    def middleware(request):

        if not request.user.is_authenticated:
            return redirect('/login/')
        # before logic here
        request.some_property = Property.objects.get(request['HTTP_X_PROPERTY_ID'])
        return get_response(request)
    return middleware

--> 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.

def global_auth_middleware(get_response):
    def middleware(request):
        if not request.user.is_authenticated:
            return redirect('/login/')
        # 'after' logic here
        response = get_response(request)
        response['X-Custom-Header'] = 'somevalue'
        return response
    return middleware
code of conduct - report abuse