Please login or register.

Login with username, password and session length
Advanced search  


You need/want an older version of sNews ? Download an older/unsupported version here.

Author Topic: Larry Ullman... on Using a Framework  (Read 3420 times)


  • Doug
  • ULTIMATE member
  • ******
  • Karma: 449
  • Posts: 6020
  • Semantically Challenged
Larry Ullman... on Using a Framework
« on: February 19, 2008, 05:35:39 pm »

Larry Ullman is the author PHP and MySQL for Dynamic Websites (Peachpit Press) and several other credible publications. I've subscribed to Larry's e-mail newsletter for some time now and find his insight on various topics to be quite good reading.

There has been a bit of discussion on the use of Frameworks in other topics on these Forums.
The following is Larry's take on the use of Frameworks, shared here with anyone interested in reading it.  :)

A framework is an established library of code that you can use to more quickly program something. This of course, is an oversimplification. Perhaps it's best to describe a framework by comparing it to what it's not.

In pretty much any programming language, you can create all the code you want from scratch. This is a good way to learn but will eventually require too much time as you continue doing big projects starting from scratch time and again. So at some point, most programmers begin using code libraries to handle some of the heavy lifting. The best established of these is Perl's CPAN. PHP has PEAR and PECL. Ruby has RubyGems (among others). For example, instead of creating a form in HTML, writing the PHP validation, etc., you might just use the HTML_QuickForm class (demonstrated in my "PHP 5 Advanced: Visual QuickPro Guide").

Frameworks take this concept one big step further, making it faster to create an entire project. Frameworks seem to be gaining more popularity over the past few years, in fact, the rapid growth of the Ruby programming language is partially due to the attention garnered by its Ruby on Rails framework for developing Web applications. I don't know if this is technically correct, but ASP.NET could be considered a framework, as well (actual programing is done using Visual Basic or C# but ASP.NET provides a lot of useful tools). If you're using PHP, there are many frameworks available, with Zend recently offering their own version. A search online will turn up many others as well as articles comparing the options.

Using frameworks vs writing your own code has pretty much the same plusses and minuses as in the OOP vs procedural argument. A framework is by definition going to be bloated. It cannot be as efficient as writing something yourself, as a framework is intended to be all things for all people.The Zend framework, as an example, is 10MB in size. That doesn't mean that all 10MB will be used in every project or hog up the server's memory, but it's still 10MB of files just to get started.

A framework will also take some time to learn how to use. This is where I point out that you should consider the documentation a framework has when you go to choose one. (As an aside, frameworks use an MVC approach to a task: model, view, and controller. Simply put, this is a way of separating the relationship between the data—aka, the model—and the user interface—the view—by using an intermediary—the controller. MVC is a topic worth looking into, if you're not already familiar with it.) You'll also need to keep an eye on the framework to see when it's necessary to perform upgrades (another good quality would be a mailing list that will notify you of updates). You'll also need to make sure that the framework supports and keeps up with whatever version of PHP (or MySQL or whatever) that you're using.

On the other hand, a framework should, first and foremost, make application development much, much faster (after you learn how to use it, that is). And, something created using a framework may be more secure and less prone to bugs (that's a big "maybe", really depends upon the quality of your work and the quality of the framework). Just as in OOP, framework-based applications are easier to maintain and update, and easier to use in group situations. If I were in a situation where I had to turn out lots of projects—like a couple of Web sites a month, mastering a framework would make a lot of sense.

Although I don't want to get in the habit of (shrugginh) my shoulders... I have to again say that using frameworks is not mandatory and it may not be right for you, depending upon your situation. However, taking some time to pick a framework, learn how to use it, and play a little bit is really a good idea.
That way, you can make the decision as to whether using a framework is right for you.
« Last Edit: February 19, 2008, 05:37:50 pm by Keyrocks »
Do it now... later may not come.
sNews 1.6 MESU | sNews 1.6 MEMU


  • Guest
Re: Larry Ullman... on Using a Framework
« Reply #1 on: February 19, 2008, 06:53:12 pm »

Thank you Doug for this article, it is very helpful.  I don't like frameworks either since I get lost after a few folders deep, and the OOP is over my head and through the woods.

sNews uses functions that can be defined as "framework"-like functions.  retrieve, s($variable), cat_rel(XXX) are helper functions, which taking the definition above, "an established library of code that you can use to more quickly program something".  But of course nothing to the extent of MVCs


  • Guest
Re: Larry Ullman... on Using a Framework
« Reply #2 on: February 20, 2008, 04:21:18 am »

Well, we've seen what "framework"-like functions such as function retrieve and function s can do to a system. Small pieces of code with a huge impact to the system performance.
OOPS behaves similar. Better said. It is human behaviour. Why writing 100 bytes of good code, when you can call a bloated function with only 10 bytes of code?

Take a look at WYMstyle: a CSS framework (no disrespect intended, css is just something I pretend to know). The pros and cons are described very well.

WYMstyle favors:

    * Speed of developement
    * Easiness of maintenance
    * Modularity
    * Reuse of work across projects
    * Centralisation of styles related to different projects
    * Ease of understanding of the CSS code.

At the cost of:

    * Optimisation (there can be a lot of independent CSS files to import, which multiplies the number of server requests, and there are lots of comments).
    * Independance of your websites stylesheets (in the case that you adopt the proposed method of hosting only one instance of WYMstyle).

The package (framework) is unpacked, almost 300 kb.

A framework can never target code as precise (efficient) as true designers can and unfortunately: It starts out as an tool to 'make a powerful systems in two minutes, while watching tv' and it ends up being pseudo code just as difficult to understand as the code being replaced.
Dreamweaver for instance, replaces code with buttons.
Is there anyone who can understand Dreamweaver's button code instantly?

Oops, being philosophical again. :-[