Guiding The Geek In You
A few nights ago over coffee at the local Starbucks I enjoyed one of those moments we as web developers secretly love: a full throttle conversation about ideal, multi-tiered web applications. As we broke down tiers and discussed their relationships, we considered different scenarios: what if the user is on a mobile device? What if their connection speed sucks? What if the site they are using has a million controls?
In fact, what if the website looked and needed to behave like a regular application? Would a massive collection of ad hoc jQuery event handlers, Ajax calls / RESTful services and finely crafted HTML be enough? Maybe. But a better solution exists. Enter the framework.
A framework is a specialized type of library. For programming languages, a library is a collection of behaviors (think: functionality) written in terms of the language, that can be called by using a well-defined interface. Libraries are meant to be used by multiple programs or in multiple areas of a single program, largely because they encapsulate commonly used functionality set apart from the program’s actual code. This makes writing complicated code somewhat easier, as repetitive / complex chores have already been solved and are only a friendly method call away.
A library is passive. Developers must write their code using that library’s interface to get anything out of it. Thus an entire program can be written never using a library’s treasure trove of functionality, even if available the whole time. Not so with frameworks.
Like the libraries from whence they came (poetically anyway), frameworks are a collection of functionality written in terms of the language they support. Frameworks are portable, meaning they too can be reused in multiple projects written in their given language. However, unlike a library, frameworks are bossy. Using a framework correctly means subscribing to how the framework developers view application organization and development. Let that sink in for a moment. Within a framework, your program no longer directs traffic. The framework becomes the traffic cop, and your program the exotic sports car (or three row SUV, which ever you prefer).
Frameworks share four attributes that set them apart from libraries. Where libraries are accessed as needed, frameworks work on the Hollywood Principle, aka “Don’t call us, we’ll call you.” The framework takes care of business and calls your program when it’s show time. The fancy term for this behavior is inversion of control. Second, a framework must have a default behavior, meaning once installed and properly configured, it has to do something useful right out of the box (typically a “hello world”). Next, they must afford some way for developers to extend their functionality, either by overriding default behavior or by creating new behavior within the internal guidelines. Finally, framework internals are considered off-limits. Extend all you want, look under the hood, show it off to your friends, but don’t touch anything inside. Modify the magic and you void the warranty.
During my research I looked at many languages. Each of these languages had at least one framework written for them. So, while a statement like “all languages have frameworks” would probably get me in trouble, I think it is safe to say frameworks have benefits that are tough to ignore, no matter the language. Here are a few popular languages and their corresponding web frameworks:
PHP: CodeIgniter, Zend
Ruby: Padrino, Rails, Sinatra
Java: Grails, Play
Python: Django, Zope2
JavaScript: AngularJS, Ember.js, Backbone
Node.js: Express, geddy, Meteor
In fact, frameworks are so helpful they are even used in CSS. Examples include:
Bootstrap
Foundation 3
Skeleton
Frameworks are not for everybody. Some are better than others in any given situation. Frameworks can have tough learning curves, particularly for the novice developer. The unusual usage demands and seemingly arbitrary control flow may seem senseless until well understood. Framework use can also lead to code bloat by adding unnecessary functionality and inspiring work arounds written by developers unfamiliar with the framework’s complexity. Speaking of complexity, take a look under the covers and marvel at the magic. Pre-implementation study and research is sincerely recommended!
These are real concerns you should absolutely consider. However, frameworks also bring a feast to the table. As well-tested and typically open source application scaffolding, frameworks can help separate concerns in extremely reliable ways, decreasing code spaghetti. In fact code quality is often amplified when developers follow usage rules and color inside the lines. Although structured, frameworks are extensible when necessary – while still cutting development time by taking care of common tasks (just like any other library). Finally, over the long-term the framework becomes invisible, improving project delivery time and code reusability.
Thanks for reading, and happy frameworking!
Use Gnome? Love gEdit? Me too. In fact I love this little brother to Notepad++ so much that I’ve begun tweaking it into an IDE, and it turns out this little brother is growing up fast.
An important function of any Integrated Development Environment – or IDE – is that it provide a built-in compiler or interpreter. Yet PHP is a server side language so getting it to place nicely outside of a web browser is tricky, but far from impossible.
In fact PHP scripts, like PowerShell or Perl, can be run from the command line. For example to run some_script.php on a machine with PHP installed and configured properly simply open a terminal prompt and type:
php5 directory_name/some_script.php
So how to bridge the gap from CLI to IDE? External Tools.
First, enable the External Tools plugin. Go to the Edit drop down menu, select Preferences, click the Plugins tab, and select the External Tools check box (should be near the top somewhere).
Now, with External Tools selected click the Configure Plugin button to open the External Tools Manager window. Four tools have already been configured for you under “All Languages” – but we’re going to make our own! Find and click the little notepad icon near the bottom left corner of the manager window, which creates a new entry under “All Languages”. Name this entry “Run” (you can change it later).
In the Edit window enter the following code:
#!/bin/sh DIR=$GEDIT_CURRENT_DOCUMENT_DIR FILE=$GEDIT_CURRENT_DOCUMENT_NAME php5 ${DIR}/${FILE}
These BASH commands assign the current PHP script’s directory to DIR and the script’s name to FILE, and then executes the same command we typed above.
In the Shortcut Key field choose a cool key combo to invoke the tool. I like asciitilde (the ~ symbol). In the Save drop down I recommend selecting Current document so your key combo also saves your script before interpreting it.
In the Output drop down pick “Display in bottom pane”, which causes the output of your script to appear statically in a new pane under your code, without appending to your file or opening a new one.
Click on the drop down that reads “All Languages” (by default) and scroll until you find PHP. Choose it, and then hit the Close button.
When you open a PHP script now you need only hit your cool key combination and boom – PHP results sans a web browser!
Hope this helps! Please post below with questions or suggestions.