This article assumes you practice semantic markup and have a fairly good understanding of CSS.
CakePHP does a number of things automatically that designers might not expect, which can cause confusion for designers and difficulty for developers in implementing markup. I hope to provide some general purpose information and guidelines to designing for a CakePHP site. I would like to make a couple quick notes first however. CakePHP is a very flexible platform where markup can be re-used very easily. The more you as a designer try to make reusable markup, the easier your developers life will be. One of the most important things that you can do is to avoid id's other than for top level wrappers such as columns. This allows the developer to change content to address shifting specifications without having to rewrite chunks of CSS in order to avoid Id conflicts in the generated markup.
CakePHP has a flexible output system that lets developers easily specify how output is generated. Unlike some applications such as older CMS systems which have a specified header and footer that are called before and after the content, Cake applications render their (x)html into a layout. Two main types of output are rendered into a layout, Views and Elements. Views are the page specific content, such as a blog post, or an entry form. Elements are blocks of markup that can be used across multiple pages, and can be used in the layout, in the view, or even from inside another element.
Form related tags can appear in any of the output region types, but it is helpful if you as a designer try to avoid having forms span multiple elements or different sections. Doing so makes it much easier to ensure that the form will work correctly every time it appears. By default most form elements are wrapped in a div with descriptor classes such as “input text” for a text field. Check boxes, and radio buttons are wrapped in a fieldset instead of a div. Also by default the form helper automatically generates id's for the form input widget, and a label that matches it. This is another situation where it is easier to avoid an id attribute and use a class name as a designer. If you specify and ID, your developer has to check that it has not been used in CSS to specify a style, or choose to override it with your specified value and loose flexibility in the future.
Examples of form widgets:
Select box:
Blog blog.
Text field:
Title
Check Boxes:
Status
Published
Allow Comments
Moderate
The other CakePHP core utility that generates a fair amount of HTML is the paginator helper. While the helper itself has been covered on the bakery before and is worthy of several blog posts itself, I'd at least like to touch on the default markup generated by the helper.
You can easily specify a string that will appear in between the spans, and each of the other elements are called separately, so they can be in other spots on the page, or have markup between. Unfortunately it is not easily possible to remove the span from the markup, but it would be fairly easy to change the pagination output to something similar to this:
Once the database has been created, bake models and controllers as normal using:
