zen of coding

A question to my readers..?

What is your approach and strategy for building the views in your applications?

If it’s a-one-man show… well, that’s certainly is admirable, but often a little extra help is needed.

Let’s say we have a designer who generally does the visuals, the mark-up including some mock-up functionality and based on that I can add CakePHP features, but even more importantly all the rich-application jQuery programming, since ideally we’d like to keep CakePHP logic in the views to the bare-minimum…

  1. Is this a common approach, something that you also practice in development?
  2. Have you got some great cutting-edge ideas, you’d love to share?
  3. Perhaps some Q&A to reach mutual goals?

Well… almost anything goes, but I’d love to see how are others handle similar situations in the MVC (well, forget the “M”) multi-developer environments.

  • davatron5000

    this is what ends up happening at my company. a design is created by our art director. then either myself or another guy will create an html/css mockup. and then that mockup is made into a theme and “cake-ified”.

  • Gordon Pettey

    If I had other people to help (I don’t), I’d want three “areas of expertise” outside of the PHP code. “Artwork” / concept design, CSS, and Javascript. Artwork person draws page layouts on paper, with an image for each possible combination of collapsible or optional elements open and closed. CSS person takes those pictures, and writes (or chooses pre-existing) grid layout (Blueprint) to fit those pictures, and labels the edges and borders and margins of elements with the class/style they need to have in their various positions/sizes. Javascript takes that CSS information and writes the code to allow opening/closing/resizing/moving pieces of the page around. PHP person then just has to stick the right stuff in.

  • I do every thing my self and it’s hard work :-). I try fit as much as I can in the layout using conditional statements show and hide different bits. After that as much as I can in elements.

    I always create the site and functionality first make it look good after. Often simple but ugly views are easier to debug.

  • When I’ve had dedicated front-end developers, what I had them do is build the markup in a static manner. Where repetition occurs (for example, a row in a table), I’d ask them to include one visualization and developers would add the PHP code to provide the iteration. This is pretty manageable and is, in some ways, actually good because it discourages the use of non-presentational logic in view. Developers stick to the “M” and the “C”, designers stick with the “V” and only at the end do developers come in to include the dynamic elements of the “V”.

    In other cases, where I’ve had front-end developers who were smart/interested/capable enough, I’d expect them to know or learn just enough PHP to write the loops themselves. I found that this was the norm. Most professionals I’ve worked with have an interest in expanding their core competencies even if they have no interest in being a hard core developer.

    If you’re only working with designers–without markup skills/interests–then everything falls to your developers anyway, so there’s not much to discuss.

    • Ouch… :)

      Great points, however. Thank you.

  • What we do here at Hookt Studios is that we have a art director that does all the design then we have a front-end designer do the markup in cakephp templates along with css. The frond-end designer has a very good understanding of the MVC pattern, php, what belongs where as far as it goes with front-end (layout vs views vs elements). Whenever he’s not sure exactly where to put stuff the back-end devs and the front-end dev chat together to find the best fit.

    The front-end guy also does most of the user interaction with Javascriot. Most of the time, he will write the ajax calls and handlers and decide with the backend guy what data should be returned and how. More often than not this is planned before actually coding any line, but sometimes the details are still being worked on during the process.

    Sometimes, when handling the data gets complex, the backend dev will handle some of the Javascript.

    I think everyone needs to understand the big picture while having their field in which they shine.

    • @Jimmy Bourassa

      Great post, thank you. I think you hit the nail on the head… especially since some of the great practices you describe equate to some of the difficulties we are facing today. (I’m sure not the first ones, nor the last ones to do so)… overall, I hope this post comes in handy to those trying to optimize their procedures, or even those who are just getting started in the crazy world of web development.

      cheers.

  • I am a print designer by education, but i currently just do UI coding and i love it.
    What we (a three man shop) do is this:

    First, I do wireframes based on manager drawings and notes, then I do hi-def mockups in Photoshop and/or Illustrator.

    When we agree on site looks, I do all the cake views with all the presentation logic, the css/html/js, including elements and helpers, in this stage I build dummy controller actions that just set the dummy data so views are wired correctly. In this stage I discuss a lot with the backend developer about the app architecture and design.

    Then the backend developer implements the actual models and controllers, in the actions we start getting actual model data, in this stage i usually rewrite, and expand the views, helpers and the css to suite the site evolving needs. I occasionally implement simple controllers and models with no heavy data crunching.

  • @All

    Thank you everyone for your responses so far. They are more valuable than you can imagine, when trying to build a solid business process, which is beyond simple coding.

    … please keep them coming, and I’ll keep up on posting some “fun” stuff about cake in exchange ;)

  • In my company, we have distinct design, front end and back end responsibilities. Design and back end teams work in parallel on the same agile user story.

    The back end team are responsible for building the entire MVC. The views we build however, are just markup, i.e. they markup the data being output. There are no extra hooks for CSS and rarely any class names or id attributes. The markup is semantic. We’ll include loops and conditionals where required.

    So, by the time that is finished, the design team will also have finished the PSD, and next the front end team can add whatever class names and id attributes and markup hooks they need and build the CSS file making the functional page look like the PSD.

    The front end team also do any presentation based JS, and work with the back end team for any clientserver integration requirements such as Ajax.

    This results in a very fast development lifecycle, because the back end team can exploit all Cake’s View goodness with things like helpers, elements and the layout, and the front end team are not wasting their time building templates with loads of markup that the back end end up replacing with output from helpers.

  • I agree with Neil, we have a similar process, just a few things to add.

    – Each time I find myself writing an “if” statement in the view, I wonder if it could be done in the controller. Keeping the view as clean as possible will help designers who only knows how to code in HTML

    – We avoid the use of helpers as much as we can. For example, instead of writing $html->link(array…) we write “>link here, so the html/css coder can play with the link adding classes, ids or whatever he needs without the need to learn cake helpers.

    – We use “foreach: endforeach” and “if: endif” instead of { }, because that’s easier to read for someone who doesn’t knows php

    I hope it helps.

  • Pingback: A question to my readers..? « nuts and bolts of cakephp | Source code bank()

  • We are a 2 developer shop, and we outsource the graphic design – but only the general look and feel plus images/icons.

    Between the two of us, we sort of split the work halfway through the Controller layers.

    We try to have simple views, but since we are both developers – we do tend to add some logic there. and the way we achieve this is by creating our own
    elements and helpers, and putting them together in a ‘portal-esque’ way.

    This makes for a clean code in the view files, albeit it is not logic-free…

  • still confuse with php code ;), btw thank for your article

  • I do mostly contract work for other companies and always Cake sites. And most of the time I am a one man show. I will get the design in photoshop format from the contract employer along with specs on site functionality. Normally I start with creating the layout/css. Then I will read through the specs and build the database and associate the models. Then create my controllers with whatever views are needed. After the site is to that point I will usually request a demo with the client..go through the site with them and make any adjustments needed.

    It is a lot of work but I would say the most difficult part of the whole process and where help is needed is the planning of the site and development of controllers. Views are pretty straight forward unless ajax is involved and even then it isn’t bad.

  • I usually create a Helper Class for each of my WebSite “template”. I put all html functions there, and usualy use code like: Widget::addMenuItem(new MenuItem(“Home”,”controller/action”));
    And something that i like to do also, is to create code for almost everything… In the end, i just use some functions to render the layout.
    All my set-up stuff, i put on the AppController, and before rendering, i send everything to the view (menus, submenus, cart items), everything with it`s right object ^^

%d bloggers like this: