Symfony is one of the most popular open source PHP frameworks on the market. The Symfony Components, however, are loosely coupled projects that can be reused as a library outside of an application based on Symfony. The component this article explores is Console (symfony/console on Packagist and GitHub), dedicated to quickly build console applications.

He goes on to talk about some of the "pros" of using the component (including built-in argument/input handing and multiple "commands") and some of the "cons" of is use (including its size and some of the built-in features you can't really work around).

After searching around online for some examples of building simple forms, I was dismayed to discover there were two different ways of building the form. I could (a) do it the long way and create specific instances of the form elements using Zend_Form_Element_X or (b) do it the short way and add them to the form by use of Zend_Form::addElement() and pass it the type of form element I want via an array. For reasons I cannot explain initially, I decided to do things the long way. Later on, I found out that doing it this way saved me from rewriting.

He includes the code for his sample form that lives in a file outside the controller so he could use it for both the "add" and "edit" actions. He shows how to plug that into the controllers, the views to show the end result and a few decorators to get rid of the default form formatting and customize it how he needed.

Being an efficient developer often means abstracting functionality such that a single function can be applied to a variety of uses across an application. Even as this decreases risk of errors, time to develop, and the attack surface necessary to secure the application it also makes implementing security more difficult.

The article talks about a project the author was working on and how, when he came across a need for a component and found one that worked, they were surprised to see how difficult it would be to secure it without adding on extra code bloat. He describes some of the issue and talks about how the development of the component must not have included any thought into things like input validation or filtering. One suggestion is to employ a firewall to sit in front of the entire application and handle all of these things without changes to the code.

I decided to clarify and also explain some of my thoughts and ideas that an e-commerce framework should hold. These thoughts and ideas may be a little rough around the edges but I wanted to give a definition to the meaning of what I feel a framework is in this case as well as items that would potentially be a part of this framework.

Some of his requirements are things like reusable design, useful/easy to use components, functionality for both payment processing and courier handling as well as a catalog system to help manage items.