When a browser (or any web client) requests content from a web server, it can tell the server what types of content type it can interpret (HTML, text, audio, etc.). The underlying HTTP protocol allows these to be specified via “header” settings—metadata that is sent before any actual content, describing characteristics about the content. The browser can send an “Accept” header—to describe what it accepts—and the server responds with a “Content-type” header. The Accept header can be quite elaborate, but what happens when what happens when these conflict? Read the rest of this entry »
Posts Tagged ‘frameworks’
The ccPhp Framework: Installation
24
May
I have a whole series of posts, waiting in draft, describing my evolving PHP framework, I call ccPhp. If you have nothing better to do than play with someone else’s dalliances, then here is a quick installation guide. A little backwards, because I’ve yet to publish reasons why you’d want to. But, if, after my eventual publications describe this framework, you decide to install it, this is the quickest place to see how to do that.
The following describes only one way to arrange the setup. I have designed the framework with few cross-dependencies. After my “standard” setup description, I will describe the few file dependencies so that you easily define your own file organization. (If you are on Windows, you can extrapolate the appropriate things to do there). Read the rest of this entry »
Frameworks: Beyond the Nuts and Bolts
06
May
Without frameworks our “big ideas†would still be stuck in the pre-industrial age. —Bill Lee, Berlin, 2008
I have been on a long hunt for a PHP framework so I was going to write up an article about PHP frameworks, but then I thought I should back up a bit and talk about what a framework is and why you should use one.
Software driven computing has existed for over 60 years. In the early days computer programming was performed using long series of numbers to represent the electronic switches tell a computer what to do—computers still work this way. Fortunately no one has to program computers by speaking computer-ese numbers anymore. With that kind of tedious programming, the most advanced programs would be tic-tac-toe games.
But numbers are the nuts-and-bolts of a computer’s operation. Designing a sky-scraper while having to dwell on every nut and bolt of its construction might limit us to working in ten story buildings. It is vitally important in designing complex systems to be able to think at more abstract, level. Programming using numbers quickly led to “assembly language” as mnemonic way of specifying those numbers, then to “third-generation” programming languages (such as C, C++, Pascal, Fortran) which allow programs to be written without regard to the numbers that the computers can actually interpret. This frees software designers to think about problem-solving without being encumbered by the tediousness of the numerical “nuts-and-bolts” needed by the computers that run the programs.
Constructing a building does not occur in isolation; its context involves the skills and machinery of those involved as well as governmental and environmental infrastructure. Over the past 30+ years, the complexity of computing has given rise to very advanced operating systems that define the context in which a program runs. Add to that, the interactions between a program and other programs or data that exist across a network or even the internet and the complexity of issues add to the tediousness of dealing with nuts and bolts. Again, if a software designer has to dwell on the minutia of all these elements, modern complex, powerful software would never be completed.
A framework attempts to encapsulate the complexities of designing and implementing software. A good framework allows software design to occur more abstractly, unencumbered by the tediousness of the contextual details of  the environment. Said a different way, a good framework allows the software designers to focus on the application’s purpose rather than the complexities of implementation.
Software is constructed in layers or components. Encapsulation is one of my favorite concepts in software design and implementation. It embodies the idea that there are specifics at every level or component within the software system that need not be exposed outside that implementation for that level. There are two key side-effects of this: (1) it prevents parts of the program outside the component from messing with or depending on implementation details which leads to (2) each component’s implementation can be changed or improved without fear of adversely affecting use of the component in unexpected ways. This leads to more stable, maintainable products.
Good programmers embed encapsulation within their design and implementation. Many object-oriented programming languages attempt to formalize this concept so that it is easy to do this. Well designed frameworks do the same, “protecting” some parts of the program from complex or variable implementation details.
There are good frameworks and there are bad ones. In a later article, I will discuss some of the issues to consider in picking a framework.
What have been your experiences in using programming frameworks?