[FX.php List] [OFF] Someting to show at DevCon CWP User Group? -> web frameworks

[Joel Shapiro]

Hiya

First - Tony (& Michael), you're in luck :-)  We've got someone coming to the group this year who's going to show us how he's using CodeIgniter w/ FM (FX specifically, I believe) and talk about why he decided to make the effort to learn it, and why he, like Dale, "will never go back".

Second - Steve: I think you make a really great point.  I thought about that kind of thing recently when a new client of mine wanted me to make a small change on a site built by their previous FM/CWP devs.  It turned out that the site used both Smarty ("PHP Template Engine") & Dojo ("JavaScript toolkit"), neither of which I knew.  I was able to figure them out enough to make the requested changes, but it really got me thinking about the line between a developer's preferred tools & the client's best (long-term) interests.  

It may be more relevant for consultants than for in-house developers (since a "house" can set their own tools & requirements), but I think it's a good thing to think about when choosing what tools to use on a job.  (For instance, I'm a huge fan now of Sass and CSS pre-processing, but if a future developer on one of my sites doesn't know or like Sass it'll be no problem because s/he could just choose to edit the plain CSS files that get produced and totally ignore everything Sass.)

Best,
-Joel


On Jun 20, 2013, at 2:28 PM, Steven Thoms wrote:

> So, it's clear frameworks are preferred here, and I use them, and largely agree.
> 
> That said, I often choose to write procedural code for a simple reason; more people can pick it up, read through it and solve a problem. When I have a small client, with a limited budget, I think the kindest, long term solution is to write a neat, well-commented procedural experience. This gives them many more options in future, after I'm gone. If the code is well commented, I believe a novice can often go in, take a peak and maybe avoid spending a bunch of money hiring a big gun with big tools.
> 
> Security often overrides this calculus, but I wanted to inject the simplicity point for discussion.
> 
> - Steve
> 
> On Jun 20, 2013, at 12:02 PM, Tony White wrote:
> 
>> Hi All,
>> 
>> First off, I should say that on the topic of web frameworks, I have more questions than answers.
>> 
>> That said, I have been researching web frameworks both in the PHP world and in the Ruby world and have some thoughts on the matter.
>> 
>> I have to confess a bias...I prefer to code as “close to the metal” as I can for any given environment. I want the shortest path from point A to point B, unless there is an advantage to inserting more hops along the way.
>> 
>> There are lots of blog posts (many of which I’ve read) that talk about the advantages of using a framework versus not using a framework.
>> 
>> There are also many blog posts on the web comparing procedural PHP to object-oriented PHP.
>> 
>> There is also a lot of documentation about how different frameworks work. I have read through much of the documentation for CodeIgniter and ZEND.
>> 
>>> From Joel Shapiro a while ago:
>> http://www.phpframeworks.com/ 
>> 
>> Having said all that...I’m currently of the opinion that it is sometimes correct to use a web framework and sometime correct to avoid using a web framework. 
>> 
>> Likewise it is sometimes correct to use object-oriented PHP and sometimes best to use procedural PHP. 
>> 
>> Any given choice should be guided by pros and cons and how they affect a particular situation.
>> 
>> I’ll start off by making the assertion that the web frameworks have greater complexity. This complexity must be balanced by benefits in order to justify the cost.
>> 
>> For an example of complexity, have a look at what’s involved using the ZEND framework to add form elements to a web form...
>> 
>> http://framework.zend.com/manual/1.12/en/zend.form.standardDecorators.html 
>> 
>> … and compare this to building a form manually:
>> 
>> http://webcheatsheet.com/PHP/form_processing.php
>> 
>> Most people would agree that it is more complicated to use a web framework for this task.
>> 
>> This gets us to the question, “what are the advantages to balance out this type of complexity?”
>> 
>> The idea behind a web framework is that it solves a number of recurring problems that will (or might) come up in any given web project. Examples include:
>> 
>> * Protection against cross site scripting attacks
>> 
>> * The ability to implement unit testing (PHPUnit, RSpec, etc.) to protect against changes breaking code, for example on large projects with multiple team members.
>> 
>> * Protection against web form spoofing.
>> 
>> * Dynamic database query generation within an Object-relational mapping pattern 
>> https://en.wikipedia.org/wiki/Object-relational_mapping
>> 
>> *** I wish I had a comprehensive list of all the things that a web framework gives you. Please feel free to add to this list. Additions appreciated.
>> 
>> A web framework is a collection of code, some of which which will be useful for a given project and some of which will not. There might be advantages in deploying only the pieces of code that are needed for a given project and in the simplest possible way.
>> 
>> For example, in the Ruby world, the 2 popular frameworks seem to be Ruby on Rails (RoR) and Sinatra. Ruby developers talk about using RoR in some cases and Sinatra in other cases where they don’t need the overhead of RoR. This method of starting with the amount of code that’s appropriate for a project seems like a good idea. There is also the question of how easy is it to  modify a framework for those cases where you need to color outside the lines.
>> 
>> The most important question seems to be what problems does a framework solve? If we can answer that question, it will help us make the best decision of when to use a framework and when to keep it simple.
>> 
>> What do you all think?
>> 
>> Thanks.
>> 
>> All the best,
>> 
>> 
>> Tony White
>> Tony White Designs, Inc.
>> Tel: 646-714-2797 (Google Voice)
>> Tel: 718-797-4175
>> tony_white at twdesigns.com
>> http://www.twdesigns.com
>> _______________________________________________
>> FX.php_List mailing list
>> FX.php_List at mail.iviking.org
>> http://www.iviking.org/mailman/listinfo/fx.php_list
> 
> _______________________________________________
> FX.php_List mailing list
> FX.php_List at mail.iviking.org
> http://www.iviking.org/mailman/listinfo/fx.php_list