The transition that we are starting right now is going to be the most important set of decisions that White Lion makes for the next 3-5 years. To help explore all of these decisions I have tried to document some of the things that I think are important. The point of this is as a starting block for discussion, I do not know all the answers to these questions, but I tried to come up with the best arguments I could to support my opinion. Hopefully you all have some thoughts!!
One thing I think we need to discuss is the benefits and drawbacks of customizing our framework environment. What I mean by this are things like changing the directory structure, writing non-standard bundles instead of using community provided bundles and choosing not to use the pre-defined functionality in favor of our custom blend.
Pros
- Being able to fully understand the code
Cons
- Not taking advantage of community contributions. This means time wasted re-inventing the wheel.
- Having to update our customized file structure when new releases of the framework come out is more complicated.
- It is harder for people to learn the framework because there is no internal documentation. And if we wanted to create documentation, it would take precious time away from client work.
- These people are very qualified programmers who are experts in this domain, so we should trust their opinion.
I think this can be broken down into a few key areas where we need to make this decision.
Comparing the default Laravel directory structure:
| application
| bundles
| laravel
| public
| | bundles
| | css
| | img
| | js
| | laravel
| storage
To the first commit for our version:
| _framework
| | application
| | bundles
| | laravel
| | storage
| bundles
| css
| images
| js
So the customization decision here is basically that the framework files would be stored under the web root rather than outside. Things I think we need to think about are testing how this effects installing bundles, publishing bundle assets and how to keep current with possible future changes.
As an example, you wouldn't change C:\Program Files to C:\Applications on Windows just because you're used to a the file structure of OSx. You keep with the defaults provided by the people that built, from the ground up, the systems we rely on. By defining things in our own way, we are setting ourselves up for inevitable problems and failure.
Pros
- More closely models our current method
- ???
Cons
- Possible conflicts with new bundles in the future
- Non-standard directory structure means a higher learning curve for people who already know Laravel
- Possibly harder to upgrade, both the core and bundles
The default bundles we include in the most basic instance of the Project Template will be the most important bundle choices we make. They will not only be the most commonly used, but also the most depended on. Because of this I think the criteria we should look at for choosing them should include some of the following:
- Flexibility: The bundle should work in all situations we encounter. We should NEVER have to fight our tools to get a job done.
- Dependability: Do we have proof that the functionality works in a dependable way. The bundles should not have erroneous errors like the old asset manager, or un-caught errors we don't know about. To be sure, all bundles we include by default should have strong unit text coverage.
- Community Support: Community maintained bundles should be our preference over custom ones. This way we can benefit from other people work and contributions.
As we move forward I think that committing to a coding standard that is in line with the under-lying framework's intentions is important. Rather than creating a "White Lion Way", I think we should learn and adapt to a way that is consistent with the recommended standards for Laravel itself.
For example, if the creators of Laravel recommend using dependency injection by way of the IOC container, then we all need to learn how that functionality works, and use it. Or, if there is a built in feature, like forms, we should make every effort to use the plain'ol framework for our first go. Then once we get a bit under our belts, we can build on top to automate and simplify our use cases. We should not be assuming use cases and hard-coding those in.
"Too much customization can hinder usability"
One of the biggest problems we have faced because of the way we setup Kohana is that we cannot upgrade along with the framework. This means that we have been stuck on a framework released in August 2008 with tons of legacy code we dare not change.
I think that we need to create a system where all groups of functionality can be upgraded independently. For example, if we are two months into a project and Laravel releases a new feature that would be helpful, the developer on the project should be able to hot swap in the new version without much effort (aka, less than 20 minutes).
This would enable us to share code much more freely across projects, even old projects. Bundles are one step to that, but making the framework files easily update-able is also important. I think this reflects back to the Directory Structure Customization section. And I think that we should probably figure out a nice way to separate Laravel directories and files in a way that upgrading would be simple.
On a slight side note, this means we should NEVER touch core framework files. Not that we do, just thought I would mention it.
We are a tech company with a collective wealth of knowledge, but that knowledge quickly becomes stale with the pace of the industry. For stability's sake we cannot jump to the newest thing all the time, but neither can we stagnate. To find that balance we need to really be on point, and not just dive in to something without knowledge.