Movatterモバイル変換


[0]ホーム

URL:


Skip to content
DEV Community
Log in Create account

DEV Community

Masonite  profile imageJoseph Mancuso
Joseph Mancuso forMasonite

Posted on • Edited on

     

Masonite Framework 2.0 Patch

The Patch and Challenge

Masonite is a pretty young framework and has a pretty young community. While building an awesome dashboard package for Masonite, I realized that a package I was working on was not working the same as it was with Masonite 1.6. More specifically, I was able to add static files to Whitenoise via a Service Provider but not I was not able to in 2.0.

Those familiar with Laravel and Service Providers, I present you a challenge. This challenge is to find what is wrong with this code snippet below.

The answer is below it so don't peak!

forproviderincontainer.make('ProvidersConfig').PROVIDERS:located_provider=provider()located_provider.load_app(container).register()iflocated_provider.wsgi:container.make('WSGIProviders').append(located_provider)else:container.resolve(located_provider.boot)container.make('Providers').append(located_provider)

Not sure what it is? I can give you a hint.

forproviderincontainer.make('ProvidersConfig').PROVIDERS:located_provider=provider()located_provider.load_app(container).register()# <-- this lineiflocated_provider.wsgi:container.make('WSGIProviders').append(located_provider)else:container.resolve(located_provider.boot)# <-- and this linecontainer.make('Providers').append(located_provider)

Find it yet? Ok I'll just tell you. This problem is that not all Service Providers have registered before all Service Providers have booted.

The Patch

The fix is to restructure the code to be like this:

forproviderincontainer.make('ProvidersConfig').PROVIDERS:located_provider=provider()located_provider.load_app(container).register()iflocated_provider.wsgi:container.make('WSGIProviders').append(located_provider)else:container.make('Providers').append(located_provider)forproviderincontainer.make('Providers'):container.resolve(provider.boot)

You can patch this in your Masonite 2.0 applications.

My Thoughts and Possible Solutions

So the framework is young and we will have mistakes like this from time to time until the framework becomes extremely stable. There were a few solutions to this problem.

Solution 1 - New Major Release

This would entail everybody upgrading the framework from 2.0 to 2.1. It would require updating the documentation to 2.1 (without any documentation changes) and would mean a lot of confusion for people who didn't get the message

So this solution wasn't really a possibility.

Solution 2 - Patch All New Applications

We could simply make the fix in all future applications of Masonite but the problem will now arise that now there are technically 2 different versions of Masonite 2.0. 1 version with the patch and 1 without. This will make packaging hard.

The Winner

The solution we are going to be choosing for this problem is that we will release the next minor version of Masonite. In this new 2.0.x version will be a new function that looks like this:

def_check_patch(self):patched=Falsewithopen('wsgi.py','r')asfile:# read a list of lines into datadata=file.readlines()# change the line that starts with KEY=forline_number,lineinenumerate(data):ifline.startswith("for provider in container.make('Providers'):"):patched=Truebreakifnotpatched:print('\033[93mWARNING: {}\033[0m'.format('Your Application Is Not Patched!'))

And we can put it inside the serve command:

defhandle(self):self._check_patch()# <-- New Line Hereifself.option('reload'):self._run_with_reloader(extra_files=[".env"])else:self._run_application()

What this will do is scan yourwsgi.py file for the patch and if it does not detect it then it will show the error when you runcraft serve.

Once you make the changes, Masonite will no longer show the warning message.


Again, the framework is young (but mature) and there may be some mistakes like this in the code. Very few parts of the framework are in the application itself so most fixes are made by upgrading Masonite itself. There are small parts of the framework that are inside the applications that are created and there is a small margin of error that can happen.

We'll need to work together as a community to find these issues and make Masonite a better framework we can all enjoy :)

Top comments(3)

Subscribe
pic
Create template

Templates let you quickly answer FAQs or store snippets for re-use.

Dismiss
CollapseExpand
 
lloople profile image
David Llop
I'm a web developer using Laravel (PHP) and Vue.js. From Girona, Catalonia.I'm always asking `how does this work?`I'm always saying `never stop learning.`
  • Location
    Girona, Spain
  • Joined

Congratulations with the framework! 🎉

There's a thing I don't understand, why you can simply use the first approach which is actually fixing the bug and releasing a minor version like 2.0.1? I think everyone using your framework should have it since I consider it a bug 🤔

CollapseExpand
 
josephmancuso profile image
Joseph Mancuso
Creator of the Masonite FrameworkNY Software Developer.
  • Location
    New York
  • Work
    Software Developer at Rothco
  • Joined

Really good question. So how all frameworks work is that at a macro level you have two parts of the application.

  1. Code that runs on the application and loads in the framework pieces
  2. Code that runs inside the package and supplies 99% of the functionality of the framework.

With number 1, it's hard to make changes here that are not breaking changes because it requires a manual adjustment to the code section. it's not something that upgrading the package can handle because its not inside the package.

With number 2, any code changes like this would simply be fixed with a minor release like you said.

This specific section of code is the category of number 1.


Also there is a small chance that packages were created with the notion that some providers are booting before all are registering. The framework is young so I'm currently aware of all packages being built but once it has a large scale repositories of packages then it would be a breaking change because now all providers are registered before booting which could possibly change how some packages function.

The framework is young enough that this solution works for now.

Does that answer the question?

CollapseExpand
 
lloople profile image
David Llop
I'm a web developer using Laravel (PHP) and Vue.js. From Girona, Catalonia.I'm always asking `how does this work?`I'm always saying `never stop learning.`
  • Location
    Girona, Spain
  • Joined

Absolutely! Thank you for clarifying this out 🙂

Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment'spermalink.

For further actions, you may consider blocking this person and/orreporting abuse

The Modern and Developer Centric Python Web Framework

More fromMasonite

DEV Community

We're a place where coders share, stay up-to-date and grow their careers.

Log in Create account

[8]ページ先頭

©2009-2025 Movatter.jp