开发者

Is CakePhp 'standards compliant' when generating HTML, Forms, etc?

开发者 https://www.devze.com 2023-02-02 10:47 出处:网络
So I\'ve been reading a lot of \"Designing with Web Standards\" and really enjoying it.I\'m a big CakePhp user, and as I look at the source for various form elements that Cake creates with its FormHel

So I've been reading a lot of "Designing with Web Standards" and really enjoying it. I'm a big CakePhp user, and as I look at the source for various form elements that Cake creates with its FormHelper, I see all sorts of extraneous

In the book, he promotes semantic HTML, and writing your markup as simple / generic as possible.

So my question is, am I better writing my own HTML in these situations? I really want to work in compliance with XHTML and CSS standards, and it seems I'd spend just as much time (if not more) cleaning up Cakes HTML, when I could just write my own

thoughts?

p.s. Here's an example in an out of the box form that CakePhp generates using the FormHelper

<form id="CompanyAddForm" method="post" action="/omni_cake/companies/add" accept-charset="utf-8"><div style="display:none;"><input type="hidden" name="_method" value="POST" /></div>       <div class="input text required"><label for="CompanyName">Name</label><input name="data[Company][name]" type="text" maxlength="50" id="CompanyName" /></div>        <div class="input text required"><label for="CompanyWebsite">We开发者_JAVA百科bsite</label><input name="data[Company][website]" type="text" maxlength="50" id="CompanyWebsite" /></div>        <div class="input textarea"><label for="CompanyNotes">Notes</label><textarea name="data[Company][notes]" cols="30" rows="6" id="CompanyNotes" ></textarea></div>        <div class="submit"><input type="submit" value="Submit" /></div></form>

EDIT: An in an indented form (indentation does not effect the standards compliance issue, but the above one-liner style is nearly impossible to read):

<form id="CompanyAddForm" method="post" action="/omni_cake/companies/add" accept-charset="utf-8">
    <div style="display:none;">
       <input type="hidden" name="_method" value="POST" />
    </div>
    <div class="input text required">
        <label for="CompanyName">Name</label>
        <input name="data[Company][name]" type="text" maxlength="50" id="CompanyName" />
    </div>
    <div class="input text required">
        <label for="CompanyWebsite">Website</label>
        <input name="data[Company][website]" type="text" maxlength="50" id="CompanyWebsite" />
    </div>
    <div class="input textarea">
        <label for="CompanyNotes">Notes</label>
        <textarea name="data[Company][notes]" cols="30" rows="6" id="CompanyNotes" ></textarea>
    </div>
    <div class="submit">
        <input type="submit" value="Submit" />
    </div>
</form>

In the above, there's those couple divs that seem unnecessary like the one that has inline CSS "display:none". I realized I can change classes and IDs of all the fields, but if I'm doing do that for each one, I might as well write the HTML myself...


My answers to your two questions are as follows:

Is CakePhp 'standards compliant' when generating HTML, Forms, etc?

Yes.

In [Designing with Web Standards], he promotes semantic HTML, and writing your markup as simple / generic as possible. So my question is, am I better writing my own HTML in these situations?

Sometimes you are better off, sometimes you're not. If your goal is to use minimal, semantic markup, you could be better off writing your own HTML most of the time. However, if your goal is to generate standards compliant HTML quickly, then allowing Cake to be what it's meant to be—a rapid development framework—is a good idea.

That said, you can tell Cake not to print some of its markup when you find it unnecessary. For example, you can suppress the div elements that wrap form inputs by using a value of false with this option: http://book.cakephp.org/view/1397/options-div


The markup output by Cake helpers is certainly standards compliant, as you can check at any time. What it could possibly be is simpler, but not much more so. The <div style="display:none;"> container with hidden input fields may be superfluous, but it's nicely grouping these fields and getting them out of the way. If you're using the SecurityComponent you'll find many more of these necessary hidden fields, which makes the wrapping <div> less superfluous. Apart from that, I have a hard time finding any really extraneous markup.

If you're not happy with the <div><label><input>[error]</div> structure, you can use the specialized $this->Form->label() etc. methods to produce only the input elements and wrap them in your own container elements. Just remember to include the $this->Form->error() as well somewhere.

I think the best way is to start prototyping your apps using basic $this->Form->input() groups of elements. Often these are perfectly serviceable in the final app as well. If during development you realize you need different markup than what Cake offers you, you can start transitioning to more custom markup. The one thing you should not do is write your own <input> elements, you should always use the FormHelper methods to produce those, since it's taking care of a lot of details that are a pain to reproduce properly by hand.

Apart from the FormHelper, I don't think there's anything to complain about in Cake's HTML markup, since you're writing most of the rest yourself.


According to the CakePHP book, the generated HTML is standards compliant.

You could override the default HTML output from the FormHelper methods by extending the Helper class.

More information here


Question already answered but maybe worth adding that this depends on which standards, and which version of CakePHP.

HTML5 form input types are not supported by the FormHelper in 1.2.x and 1.3.x, for example

echo $this->Form->input('User.email', array('type' => 'email'));

will output something like

<div class="input textarea">
    <label for="UserEmail">Email</label>
    <textarea id="UserEmail" name="data[User][email]"></textarea>
</div>

Apparently this will be fixed in 2.0.x.

Another edge case is if you have more than one form on the page with the same model you may end up with duplicate HTML identifiers.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号