On the road to Da Vinci 2.0

Dear community of developers,
mercy, peace and love be yours in abundance.


I'd like to share a vision why bleeding-edge solutions scare and how to craft it more friendly with a case study.

Every development stage begins with a root folder, empty index page and text editor. In late 90s I used plain HTML with a couple of SSI for permanent header and footer later on. Nowadays I'm with PHP, principally because of wide hosters support, and JQuery for a sleek and smooth interaction (like gathering feedback without reloading or hiding irrelevant sections in FAQ).

New data comes, technologies change, project reflects that following universal laws of nature.

Imagine you're Leonardo da Vinci. In childhood there is a welcome plate with your name, some surrounding sketches you draw on a workshop's backyard and information for travelers on how to reach your beautiful village. Dreamy, huh?

With the course of time your scope and depth of interests grow. You're not attached to sketches anymore, therefore moving them to /art/ together with architecture, paintings and sculpture. To introduce your recent researches for debate, you create /research/ and fill it with anatomy, botany, geology and optics. According to historians and personal anticipation, plenty of engineering insights are ripen, so you reserve /inventions/ as well.

Manifestly new pages differ in design, yet they have common elements. So how to reuse layout wisely?

First thing I've learned is template inheritance. This feature comes with server-side languages like PHP, Python, Ruby. In a nutshell it allows you to have a parent page with common markup (viz. head, nav, footer) along with children pages (requested via browser) that load parent subsequently replacing or extending it with request-related data. Eventually you don't repeat yourself. Beyond doubt this magic could be mastered by native inline programming, however I prefer human-oriented solutions with a short learning curve acting as a layer between geek stuff and essential needs thus anyone around netglobe could evolve. I believe PHPTi is the easiest and well-documented one to get acquainted with template inheritance.

Speaking of layout magic, curious persons could go even further and try extras like HAML, w2tags or Jade to simplify markup habits typing %li instead of <li></li>. So pity this trend is not popular within PHP community (e.g. HAML ports such as PHaml, phpHaml, Fammel and PHamlP are neglected to date).

Right, and what about elements decoration? There's where SCSS, LESS, CSScaffold or Turbine comes into play and makes it possible to keep DRY inside stylesheets by using variables (color: $linkcolor), expressions (height: $bodylineheight * 4) and intuitive nesting. Again, it runs in-between so you stay powerful without headaches. Check official examples, they're truly inspiring, enough said.

Idea is about changing approach as project grows. Changing approach without frustration in consequence of painful dissonance between tech-savvy raptures about some bleeding-edge solution and errors you catch for hours. And yes, I do explicitly omit narration of merging, minifying, versioning and chained loading as being enhancements, not a core.


CHILDHOOD
index.html
sketches.html
contacts.html

MATURITY
index.php
/content
    /art
        /index.php
            architecture/*.php
            paintings/
            sculpture/
            sketches/
    /inventions
        /index.php
    /research
        /index.php
            anatomy/
            botany/
            geology/
            optics/
    /templates
        /common.php
/images
/inc
    /css
    /js
    /php


Superb? Not yet, although it's widespread. Obvious drawbacks? Every page request invokes compilation cycle (common.php+requested page). Solution is to serve static cache generated in advance. (How?) Content edit requires accessing one or more files. Solution is to keep content in database. (What's the best practice?) Markup is mixed with content and sometimes, ouch!, with raw PHP. In short, framework built with MVC principles is a saviour. (Erhh?)

- Hey! - exclaims someone like me, a guy or a girl not that bright in development, but doing best to go with the times, - Now you sound like a politician! Dainty slogans followed by non-system mumbo-jumbo.

Indeed, it must be admitted. Widely-known MVC frameworks from Symphony2 to Smarty3, from Kohana to Yii, from CakePHP to CodeIngniter claim to be fast, secure and easy to learn. Really? Does one look for speed and security from the word Go? No. I dare say evaluation of how new scenery jars on habits goes in the first place. That is what will happen to the current beloved hierarchy, links, diligent markup, blocks of program code achieved through much suffering, etc. Either you convert a couple of pages successfully & feel you're quite at home or alas & alack!

Today I dimly know something concrete about autoloaders, helpers, filters, routers, models, views, controllers. It all came to nothing, but I'm eager to grasp it in the process of gradual transition like bricklaying. Gradual - not at once, you see? Stop bragging of how your framework conforms to geek-invented paradigms. Draw more parallels out of the world behind real windows, give more humanly narrated cases like one about da Vinci and optionally reinforce them with strong visuals. Gradual bricklaying is about hook people on the familiar language and accustomed practices.

I do believe this is the reason why JQuery is a leading javascript framework whereas MVC frameworks exist without leader.

Fathers of computer evolution and their honourable assistants, while you're polishing bottlenecks and contributing on benchmarks, public ashore still gaze at schooner called Bleeding-Edge-Solution with no ladder to step aboard. Ladder across the abyss of Coding-Horror. Throw a ladder at last!

Meanwhile, I thank you with all my heart for your enthusiasm.

--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.
 
 
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php