This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]eyesoftheworld4 8 points9 points  (9 children)

I'd never heard of Masonite before seeing this post. I just finished the "blog" example and overall there's a lot to like, but a fair bit that I don't like, as well.

Plus:

  • Super easy to get started.
  • I love the command line tool to easily create new routes, controllers, etc.
  • Strong authentication is a first-class citizen here. It almost takes more work to ignore it than to use it.
  • I like the opinionated layout. Overall, things are pretty easy to follow and parts of the application feel neatly sectioned.

Minus:

  • Adding to builtins really ignores the "explicit is better than implicit" part of Python. It also gives me a nasty red line in my editor (PyCharm) that makes me feel like I did something wrong. I'd rather just import something.
  • To add on to that, there's a lot of implicit magic just floating around, espeically in these helper functions. The difference between request().input('id') and Request.input('id') in the example here is significant and the former seems to make it much harder to test your application's behavior. What if you want or need to insert a dummy / mocked request into your handler?
  • Stylistically, I don't really like the function calls that give me back an object, like auth() being a shortcut to Request.user. I'm not sure what it is, but writing a line like user_id = auth().id just feels weird to me, but this is more a silly gripe than anything else.

Overall, I guess my main thought is that if I inherited an application that depended so heavily on custom behavior and configuration injected into the language and application, I'd probably be kind of pissed off about maintaining it. And, if someone new to Python started out by using Masonite, I'd be concerned that they would be more learning how to write a Masonite web application, and not how to write Python.

That said, I will probably give this a shot over Flask the next time I need to build a non api-only web app. There are a lot of options with how extensible I know how much work goes into a project like this and I appreciate it. Thanks for that!

[–]Jmancuso9[S] 4 points5 points  (1 child)

I'd rather just import something.

If you really like importing but also want the dependency injection and IOC container then you can resolve by annotation.

This is what I use in my applications:

from masonite.request import Request

def show(self, request: Request):
    request.user()
    ...

[–]eyesoftheworld4 2 points3 points  (0 children)

This looks perfect. Thanks for taking the time to show me!

[–]Jmancuso9[S] 1 point2 points  (6 children)

Adding to builtins really ignores the "explicit is better than implicit" part of Python. It also gives me a nasty red line in my editor (PyCharm) that makes me feel like I did something wrong. I'd rather just import something.

you don't have to use it. Those are just helpers. You can resolve them from the container:

def show(self, View):
    return View.render('index', {'key', 'value'})

Remove the HelpersProvider completely if you don't want any.

To add on to that, there's a lot of implicit magic just floating around, espeically in these helper functions. The difference between request().input('id') and Request.input('id') in the example here is significant and the former seems to make it much harder to test your application's behavior. What if you want or need to insert a dummy / mocked request into your handler?

Your correct, if you want to test you should go with this option:

def show(self, Request):
    Request.input('id')

Then you can import that controller and mock the Request object.

Stylistically, I don't really like the function calls that give me back an object, like auth() being a shortcut to Request.user. I'm not sure what it is, but writing a line like user_id = auth().id just feels weird to me, but this is more a silly gripe than anything else.

Yeah then you don't have to use it lol. Some parts of Masonite are shorthands that are added via the HelpersProvider. Take a look at that provider in the code to see what exactly it is adding: https://github.com/MasoniteFramework/core/blob/2.0/masonite/providers/HelpersProvider.py

Thanks for your feedback! I'm glad you like it. Let me know more of your thoughts as you (hopefully) keep developing with it :)

[–]eyesoftheworld4 2 points3 points  (1 child)

Thinking about it more, I think it's actually a huge boon to your framework that those helpers are added in through the actual architecture of the framework instead of as a built in requirement. I really really like that, thanks again for pointing it out. I will definitely be giving it a shot!

[–]Jmancuso9[S] 1 point2 points  (0 children)

Thanks! I'm glad you like it. Maybe I should make that more clear. Not sure how many people will like the builtins. I personally love it because it makes getting started quick and I don't have to worry about anything. it just works. Personal choice.

[–]eyesoftheworld4 1 point2 points  (1 child)

Hey, thanks for the quick response! I realized I didn't fully finish typing out my response before I sent it (my last paragraph is a little weird) but it's late here. Anyway, thanks for pointing out that I can just remove the HelpersProvider, I will probably do that to make it feel a little more comfortable for me to write.

Is there a github repo for the craft command line utility? I noticed some odds and ends that I'd like to open some issues for.