This lets the user specify a label or title in the Model for each field. They will automatically be used when outputting a FormHelper input. Since the label/title rest as a Model attribute, it can be altered or set at many places (e.g. in constructor, at definition or in a Controller).
Added default Model labels on the label, which are used when using th…
…e FormHelper to generate an input element
IMO labels info belongs in the view layer not model layer.
Thanks for your comment :)
I see what you mean, but I also think that it helps to create cleaner add/edit/detail views. Today, you have to re-enter the same label over again in all three types of views. You can of course reuse the same files in an element, but if you want one field not to be shown in any of the views you have to make ugly exceptions.
Also, I see a win in list views where you can fetch the header for a column. With this feature the label will be consistent over all four views.
If you create English applications then the auto-label-function will work just fine, if you set clever names on the columns of your database. But when creating applications in other languages (e.g. Swedish) you'll probably want the column names the same way (in English), but the labels in Swedish. As for now, you must enter those labels in all views. If you want to change a label, you will have to do that in all views.
The auto generated label text using db field names is run through the translator function.
I'm not really sold on the value this provides. It seems like another layer of auto-labelling, and in the wrong layer like @ADmad said. Text labels are primarily a view feature. Other view-esque properties like $title are also used with find(list) so they have some reasons to stay. I think this is the type of problem you can solve either with elements, or creating higher level abstractions on top of the form building tools. Many times in the past people have requested less coupling between models and forms, and I tend to agree with those thoughts. This seems like a step in the opposite direction.
I simply extracted this, and improved it a little, from an extended FormHelper and an AppModel that I've used in my projects. I find it quite convenient. But as you say, that is maybe where it should stay - it shouldn't be a part of the core.
Thanks for your comments. I can see why this might not be a good idea for the general CakePHP developer.