Hi, this e-mail is really long and hard to understand. I read the whole thing and I don't even really know what your question was, or what you are looking for in a response from people.
- Jon On Wed, Mar 2, 2011 at 11:17 AM, Alexander Sergeyev <[email protected]>wrote: > 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. > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en > -- Connect with me on *http://twitter.com/jwage* <http://twitter.com/jwage> and http://about.me/jwage to keep in touch. -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
