WISPBill / WISPBill-Web-App

A Laravel App for running an ISP or WISP. It can do Billing, User Management, Monitoring, Provisioning and much more
GNU Affero General Public License v3.0
13 stars 13 forks source link

Implementation #1

Closed tmcdon89 closed 8 years ago

tmcdon89 commented 8 years ago

First and foremost I'm glad to see its a laravel project!

Being based in laravel I propose we build WISPBILL as a package. The basics can be found here: http://laraveldaily.com/how-to-create-a-laravel-5-package-in-10-easy-steps/

Building as a package will allow new users to install WISPBILL with much less interaction. Additionally it will allow for it to be installed in conjunction with preexisting projects.

For syntax of WISPBILL within the code, is the plan to keep it all caps or drop it to lowercase?

turtles2 commented 8 years ago

I don't think a package is a good approach. Because this project will do do so many different things I don't think it will lend it's self well to that format. From my reading of the Laravel docs

Packages are the primary way of adding functionality to Laravel

Quote from Laravel Docs. I see this project as an application to run a WISP with. Please let me know your thoughts or if my understanding of packages is wrong. I see the WISPBill using packages like Ticketit. To be a super modular application.

As for formatting of the name I think it should be like this WISPBill so that WISP as an acronym is capitalized then the B in Bill is capitalized to stress what it does.

tmcdon89 commented 8 years ago

That's a fair enough reason to produce it as a project. The primary reason I was looking at it as a package was for installation purposes. Packages can have all of the bells and whistles of a full on project with the ease of installation and upgrades through composer. Running it as a standalone project will require the end user to correctly place all of their items in the corresponding folders of their laravel installation. I don't think this will be a major issue as long as everything is properly documented.

If we go that route we should consider sticking to the inclusion of only the necessary folders within the repository so that its not overwhelming.

The primary folders and files that should be needed from the laravel installation are: -app -config -database -resources potentially -public composer.json

I think thats everything essential for it to function. That should also exclude things that we don't necessarily want to all be the same across all installations. Such as the .env file which lays out the sql database to be used etc...

tmcdon89 commented 8 years ago

I'll set up a pull request with what I've currently got in our system. That way you can see if there is anything you'd like to reuse from what I've done previously. It shouldn't take me too long to scrub it out for anything specific to our business.

turtles2 commented 8 years ago

Yes everything will be documented. I agree about the files and to that end the project already has git ignore ignoring those unneeded folders. They will show up in the structure but nothing in them will. I guess if you think we need to we can also remove them from the structure.

turtles2 commented 8 years ago

Awesome after the pull request I will close this issue. As I believe we have it all sorted out.