Gary and Leam, I also agree.
Over the past few years I have worked on 3 “homegrown” MVC frameworks. 2 of these were business applications (inventory, ERP, that sort of thing.) and that’s the use case I’m thinking of here. I didn’t design them or code them and had no involvement in the creation of them. My experience has been that it’s like learning whole new programming language that just happens to be built with PHP. Most of the development time is spent in figuring out how to get the framework to do what I want. (or rather, figuring out how the framework works.) These are/were proprietary frameworks so there is no “community” to reach out to. On 2 of these, I have (at times) been the solo developer who has inherited the system after the creators left. One thing (among many) that I find makes it hard to work on these systems is the use of default behavior. Gary’s example; > <?php > > $app = Factory::getApplication(); > $app->execute(); > ====== I have no idea what that does until I read thru the code and find out what the default is. (or if I’m lucky, there will be some documentation.) On the surface, it tells me very little about what it’s doing. I’m currently working on re-designing one of these in the hopes of creating something that is easier to learn and work with. So far, the plan is to use an MVC pattern with controllers that read top down like an actual program. Mostly static “helper” functions that take arguments and return something. Any dependencies are passed in as arguments. I’ll end up “repeating myself” in these, particularly in ares like input checking, user auth, data access auth and so on. …and for me, and for this application, I think that’s ok. I’m using objects only where I really need them, and avoiding extending on classes where possible. I’m hoping to end up with controllers that any competent programmer could read and understand quickly. Controllers that revel the flow of the application. Sort of like this; <?php // sanitize/validate input // make sure the user is logged in // make sure user has access to the requested data // use the model to get the data // apply any business logic // $view_data = XyzView::render($data); // template::Render($view_data); That’s not a great example but you get the idea. I have a top down controller that is readable and as self documenting as possible. No default behavior and nothing obfuscated. I don’t think this is a very popular approach these days but I do think that it will serve well. I’d like to spend more time creating solutions and less time wrestling with edge cases that have to be handled in some class that’s buried at the root of a bunch of extends. I’d like to handle my edge cases in plain view with a controller that’s designed to handle them. Hopefully my controllers won’t “pollute” each other. Like most of us, I’m still learning more every day and I realize that this is not an “either or” situation. I will have to adapt as I move forward with the work and things won’t work out exactly as planned. But I’m hoping to end up with more readable code, and a system that gets out of my way and lets me do what I need to do. My experience is that it’s expensive to maintain the more complex “obfuscated” systems and the learning curve for new hires is high and long which adds to the expense. Of course, I’m not saying that every project should be done this way. Just wanted to throw in my 2 cents. Thanks for reading! Glenn On May 22, 2014, at 2:11 PM, leam hall <leamh...@gmail.com> wrote: > Gary, > > I'd have to agree with you on this. We can be happy that PHP is now a > professional grade enterprise capable solution. However, frameworks, "modern" > coding practices, and a host of other things make it very difficult for > someone to climb the learning curve. > > That may be just my perception. > > Leam > > > On Thu, May 22, 2014 at 10:49 AM, Gary Mort <garyam...@gmail.com> wrote: > Anthony's comments on my last post reminded me of an issue I feel PHP is > facing today. > > ===== > <?php > > $app = Factory::getApplication(); > $app->execute(); > ====== > > -- > Mind on a Mission > _______________________________________________ > New York PHP User Group Community Talk Mailing List > http://lists.nyphp.org/mailman/listinfo/talk > > http://www.nyphp.org/show-participation
_______________________________________________ New York PHP User Group Community Talk Mailing List http://lists.nyphp.org/mailman/listinfo/talk http://www.nyphp.org/show-participation
