If MVC or object oriented programming are new concepts for you then using a framework is probably going to be a fight for you. These two concepts are really the key to making this thing save you time and effort.
When I first started writing dynamic pages a lot of what I was doing was just encapsulating html files in a php file with a bit of dynamic stuff thrown in. I really only wanted database access and session management and didn't use PHP to create the pages in any substantial way. This lead to having files included that contained the header at the top or the footer at the bottom but those files were really not much more than basic HTML anyway with some variable substitution or the odd if statment.
In other words I was writing HTML with some PHP. I think that moving to a framework requires a shift in thinking that you are writing a lot of PHP and a little HTML. I want the program to create the pages and I want to write as little actual HTML as possible. Rather than include a header from a file I should have that in a variable somewhere that can be included on the dynamic page.
My first nudge towards frameworks came from trying to implement security levels. Unregistered user, registered user, moderator, administrator. This is not rocket science here, and yet my files started becoming such a tangled mess that I knew there had to be a better way. My first foray into frameworks was CodeIgniter. I might still be using it today except that it doesn't seem to be as actively developed as other frameworks. Still if you're looking for something more entry level I can highly recommend trying CodeIgniter. It can help you understand MVC with less complexity ... after all, with great power comes great documentation reading.
So back to the project at hand. I know what I want from my landing page since I've done a story board already on paper. Yes, paper. I hate flipping between screens and no matter how many monitors I have I somehow manage to fill every pixel with work that I don't want to move. Plus paper is easy to transport to the laundry room when I have an hour and a half of sitting watching clothes get clean. Even if I had done an electronic design I'd still be printing it, easier to mark off what is finished and what's not with a highlighter.
My basic features will involve different views based on whether the user is logged in or not, an image of the day sort of splash, a site search bar, a header and a footer. Again, not rocket science but there's enough going on here that I need to know what my database is going to look like or at least where it lives and what the accounts associated with it are, how I'm connecting to it, how I'm managing sessions ... and of course fall backs if any of the above fails. In the wading pool of flat HTML we've just jumped into the ocean.
Having done all this in PHP at different points in different projects I know how some of this stuff should work behind the scenes and it's exactly that approach that I want to avoid. Most of these things have been solved so many times that it's not just reinventing the wheel, it's almost lazy NOT to use established solutions.
Instead of even starting an index.php file I turn my attention to the Laravel configuration files because ultimately the reason for using a framework is to get away from those details and be able to focus on the project.
For the most part the app.php file is well documented. The implications of choices here are not yet clear but here's what I've done:
- name: changed name to my website's name
- env: apparently it can be set to local but it doesn't seem critical for developing right now so I'm leaving it alone
- debug: I changed false to true, I want more detailed output on errors but this will have to change back later on - the first note on my deployment to do list
- url: for now this is just http:/localhost/ but it will need to change, though since it's used with Artisan I may not need to change it for a while
- timezone: took a little research but any PHP time zone value is acceptable here ... now that I know how to change it I question whether I should or rather if I should set it to a localized value for the user, another question for down the road
- locale and fallback_locale: it is not clear from the localization documentation whether you can use any string you want for a locale, but my guess is yes, as long as you create the relevant language directories to match up. You may want to use the PHP locale values in case you have to pass the local to another application. For now I'll leave them as "en" since that's my native tongue.
- key and cipher: at this point of things I know that the key should be set but my configuration only says 'key' => env('APP_KEY') ... An answer on Stack Overflow explains why my key should have been set on install and why it is in fact set now. It also demonstrates to me that I shouldn't be editing \config\app.php but that I should be editing \.env I'm leaving cipher at the default.
Now that I know I should be editing .env a quick look through at the log and log_level settings are satisfactory ... single and debug respectively. If I need to change these in production I'll revisit them.
A nice discovery this file, I also see the opportunity to start my database configuration directly rather than elsewhere, though I do not yet see how to create different database user accounts for reading and writing.
As my posts are wont to do this is getting long. The basic configuration seems done and the default index.php is correctly loading from /public/ as http://localhost/ and the next steps remain database connection and sessions.
Not so scary after all eh?
No comments:
Post a Comment