As in Laravel, if a system hasn't been properly configured, this error will popup. In Laravel you do a simple hack and it will overwritte the default length of VARCHAR. How do you do this in Masonite? I explicitely set the chars length in the User migration file:

table.string('email', 191).unique()

Types of websites

• Blog

• Static Portfolio Site

• Some kind of SaaS website that uses Masonite Triggers and Masonite Clerk

There may be some discrepancies between Mac and windows support. a known one is the forward and backwards slashes which was fixed in a PR on josephmancuso/masonite-core

Checklist

• pip install masonite-cli works
• craft new works
• craft install works
• craft serve works
  • with PR from masonite-core
• make migration works
• migrate works
• database connections work
• make models works
• craft auth works

as the framework grows, this framework needs a branding to get on par with other frameworks out there. This needs to be a movement, not just a repo.

If anyone is really good at graphic design :)

Some folder named kernel maybe? but deeper inside the file structure? Doesn't really matter where it is as long as it makes sense

Ensure that there is a COMPLETE separation of migrations and ORM choice

I really like the idea of passing a template to a Mail object to send mail

Mail class needs to support variables and views
Mail support will look something like:

from blah.mail import Mail

Mail(Obj).template('path/to/template').send()

Keep this lower level and separated from any form of models. Models need to be 100% swappable. It needs to be a "use the orm you are comfortable with"

No need to rename this as it will be completely removed

There are three different forms of comments that should be added at a minimum.

Module docstrings

method docstrings

normal comments

Flagpole comments

Since it is the industry-standard protocol for authorization.

This is my stacktrace

Running sudo apt-get install python3.6-dev solve the problem for me, my virual environment using python 3.6.

This should be fairly simple. The hardest part will be getting the layout down right. We will have to wrap the wsgi server in a try and catch block and then if anything fails, pass simply just pass a view with the traceback data and construct an any to read webpage out if it. It MAY look something like this:

Make this a service provider

# inside bootstrap/start.py
import masonite.view import view

def app():
    try:
        ... code ....
    except Exception as e:
        data = view('masonite.exceptions', {'e': e, 'traceback': traceback})

    return iter([data])

Look around on the web for ideas on a good layout for debugging

need to rewrite this in Python 3.6

Just watched a video about something completely irrelevant to what i'm about to talk about but the video talked about habits which consist of triggers and action (and rewards).

I think the idea of triggers and actions. This is just a thought but I'm thinking of having a structure maybe like:

app/
  triggers/
    SendMailTrigger.py

and SendMailTrigger.py might look something like:

from app.User import User

class SendMailTrigger(object):

    def __init__(self):
        pass

    def action(self, obj):
        obj.sendMail()
        User.updateSomething()

    def anotherAction(self, obj, anotherObj):
        obj.sendWelcomeMail()
        User.updateSomethingElse()

These classes can be "triggered" by doing something like:

Registering them inside config/triggers.py

TRIGGERS = {
    'someAction' = 'path.to.module.class'
}

from masonite.helpers import trigger

# goes to the dashboard page

class DashboardController(object):
    ....

    def show(self, request):
        ... do some code ...

        obj = SomeObject()

        # Will default to the `action` method
        trigger('someAction', obj)

        trigger('someAction@anotherAction', obj, secondObj)

This will come in the form of an addon with a publish command

The Setup

The setup should look something like:

$ pip install triggers
$ craft publish triggers

craft publish will create or append the config file for you as well as create a default trigger inside app/triggers/DefaultTrigger.py

as well as come with a new craft-vendor triggers create command.

All you'll need to do is add any classes you want to trigger inside the TRIGGERS config and then use the trigger function wherever you want.

It looks like mine.py is basically WSGI file, just named differently. It can be easy way to remove some mist of confusion :)

• Choose a cool name!

• Create a description for your project.

• Add a README.md file containing all the basic information about your project.

• Create a CONTRIBUTING.md file containing all the necessary information so that other developers can help you.

• Add a .gitignore file containing everything you do not want versioning .

• Select and add the best license for your project.

• Choose a methodology versioning and follow.

• Create a roadmap to make clear the course of the project.

• Document your project in the best possible way.

• Describe your Releases clearly and objectively or create a CHANGELOG.md file and do it there.

• Use badges to indicate the status of your project.

• Configure and add a .editorconfig.

• When necessary do not hesitate to create a website for your project. Enjoy and publish with github pages.

• Write automated tests

• Integrate your tests a Continuous Integration service.

• Provide your project in the appropriate package manager. (EX: bower, npm, etc...)

we can add a lot of helper functions to the Request class. I think a good one to add next for the next release is a user() method.

A way to get the current user is:

import masonite.facades.Auth import Auth

def controller_method(self, request)
    user = Auth(request).user()

we could add support for something like:

def controller_method(self, request)
    user = request.user()

All this entails is moving the Auth functionality into the request object.

@afdolriski or @ondoheer Is this something you'd like to do?

include white noise out of the box

On https://github.com/josephmancuso/masonite/blob/master/CONTRIBUTING.md on the getting started section it says :

This repository will be updated based on this repository

What is this actually mean ?

Masonite Clerk is in development and will be released with version v0.3.1.

Masonite Clerk 0.1 will provide support for easy and simple integration with stripe charges and subscriptions. It will be dead simple to setup (shooting for < 5 minutes)

Masonite is not currently open sourced (haven't uploaded it to GitHub yet). If anyone is interested in working on it let me know i'll up get it up before it's complete

Complete and Incomplete checklist.

• Charge a user

• Create a customer out of the user model

• Retrieve customer

• Update customer

• Delete Customer

• Subscribe a user to a stripe plan

• Cancel a subscription

• Update subcription

• Retrieve a subscription

• Prorate Plans

• Make plans swappable

  • swap plans and prorate users

• create prorate toggle method

Boolean operations (quick checks)

• subscribedToPlan()

  • should accept a string to check for that plan
  • if a list is passed, check that list of any of those plans match
  • this method should check the specific stripe plans the user is subscribed to

• subscribed()

  • if no parameters are passed, check if the user has any current subscription
  • if a string is passed, check if the user is subscribed to a specific local plan (not a stripe plan)
  • if a list is passed, check if the user is subscribed to any of the local plans

• cancelled()

  • check to see if a user cancelled a specific plan.
  • if blank it will see if any plans were cancelled by the user
  • if a list is passed it will see if any of those specified plans were cancelled

Test another wsgi service (like uwsgi or similiar)

This file is the child of testing out functionality and learning how wsgi works. It was filled with prints and sanity so needs to be put inside classes and abstracted.

I find the way you are following the Laravel patterns so clearly, but having worked with laravel on many projects, I find we always end up modifying things. For example, on large projects, we always end up creating an http/models folder to order them as we require, would you find it purposeful to modify this basic behaviour?

Introduction

Middleware is basically a layer that can be added to each request. It can be thought of that each middleware adds a new layer to the stack.

How it can be done

There are basically 4 types of middleware.

1. Middleware that runs before every request
2. Middleware that runs after every request
3. Middleware that runs before certain requests
4. Middleware that runs after certain requests.

• For the first two we'll need to add middleware to a list somewhere. Middleware can live inside app/http/middleware This part is up for discussion and could be inside a new app/http/kernel.py file similar to Laravel. It could also reside in config/middleware.py. It could also be in some other place that makes sense if anyone has suggestions.

Configuration will look something like:

MIDDLEWARE = {
    'authentication': app.http.middleware.Authentication
}

or possibly even

MIDDLEWARE = {
    'authentication': app.http.middleware.Authentication.__class__
}

which ever one makes more sense during development.

• For the last 2, these can be inside app/http/middleware as well like normal but just not added to the list that runs every time.
  • These types of middleware, will be added to the routes inside routes/web.py. The middleware syntax can either be a list or just a bunch of routes. This syntax will look something like:

Get().routes('url', 'Controller@method').middleware('authentication', 'members')
Get().routes('url', 'Controller@method').middleware(['authentication', 'members'])

I think it's ok if it can be either a list or a bunch of middleware because we'll likely have to convert it into a list anyway so we can iterate through it.

Where to iterate through it.

We'll have to add it to the bootstrap/start.py file. Again there are two types of middleware, before and after. so we'll have to put it inside the app function before and after the view.

This is a key file and primarily for developers and where the request lives and dies so needs to be well commented on what is actually going on.

Need a way to pass url segments into the view:

This URL: /some/{url}/{here} should pass url = value and here = value into the view. or a dictionary, or just inside the the Request object and fetched with something like request.segment('value')

NOTE: Implementation of this should be discusses via the pull request

This error happen when i try to run craft serve command, i think this problem has something to do with changes in mine.py to wsgi.py but i didn't find where the code is executed.

verify only Python 3+

This needs to be changed and go from the migrations that are generated into a configuration file

currently there are 3 migration engine supported via Peewee ORM. When python craft makemigrations migration_name table_name is ran, it generates a migrations inside databases/migrations and puts a MySQL migrator engine inside it, this needs to be generated based on a setting set inside config/database.py

right now the SASS support is built in but the libsass library takes a long time to install.

consider either:

• sticking it out as the only time the dev has to wait is when creating a project
• make an environment variable to set SASS to a bool so the masonite.storage.compile_sass
  method is not ran without the package installed

OR only run if the libsass package is installed. This could be really good since the developer just needs to pip install libsass and nothing else to unlock full support of sass

This needs a mkdirs line right above where the line where the models are created. This should be inside the josephmancuso/masonite-cli repo

I'm going to keep the lack of a models folder but after this issue you can easily do:

craft model Models/NewModel.py

One of the thigs we struggle most on large Laravel projects and was really easy to solve in Flask was the project structure. I know there are ways to acomplish this in Laravel, but it's unnatural and when Laravel updates it just might not work.

Maybe giving the users the felxibility to work like this or having a create module craft command?

add docstrings to all framework classes and methods

avoid a forms type class like Django

Add a complete auth system

Please list all ideas for official packages that will integrate directly within Masonite.

On names subject to change

• Masonite Clerk

Repo found here

Docs found here

This will be a package that allows adding subscriptions to users. This will only work with the default Orator ORM. The simple setup will be similar to Laravels Cashier

• extending the user model with a class that contains additional methods
  • subscribe(),subscribedToPlan(),unsubscribe(), charge()
• simple copy and paste migrations
• the new craft publish command which will be available in masonite-cli==0.30

• Masonite AuthHub

Simple integration support for third party oauth services. Will come with the GitHub driver but can be used with other drivers as well like Facebook, Twitter, LinkedIn

You should be able to name your routes like:

Get().route('/home', 'Controller@show').name('homepage')

so that later we can do something like

request.redirectTo('homepage') or request.redirect().name('homepage')

instead of constantly having to import the controller, we can do something like:

ROUTES = [
    Get().route('url/here', 'HelloWorldController@show')
]

this will parse the controller out of the string

The parsing will need to be inside app/start.py but could be abstracted into a seperate class or apart of an existing class like Request or Route

Need an easy way to install third party packages. The first Official package will be:

Masonite Billable

Which will allow you to easily charge and subscribe users. This package may not be built in by default but will have very easy integration.

Will Need:

• A simple <= 2 step process for implementing a package.

This will probably entail something like:

$ pip install masonite-billable
$ craft publish masonite-billable

The craft publish is where the simpleness will happen. This may require something like masonite.packages module to ease integration. Something like:

from masonite.packages import create_or_update_config, create_service_provider

create_or_update_config('path/to/config.py') # grab the contents of this and integrate into `config/config.py` (or whatever the config name is)

Creating simple packages for masonite should take < 30 min. Will need service providers to somehow easily tap into the framework by simply passing them into the service provider. Or they may not need to be a service provider, only a config file.

also make a craft command for getting packages up and going as well.

$ craft package package_name

Thought Process

All packages may need some defaults. If my package name is masonite-billable then Masonite needs to search in a specific location.

Thinking all packages need to have at a minimum.

package.integration.boot method which will be called and all integration functions will be in there.

or a package.config file and Masonite can run with the options there.