cake bake help

Anyway, its usage is quite straight-forward. With

cake bake plugin demo

you can generate the structure and the base files for a plug-in with the name “demo”. This actually creates the following structure and files in app/plugins:

demo
  controllers
    components
  models
    behaviors
  views
    helpers
  demo_app_controller.php
  demo_app_model.php

With

cake bake plugin demo controller
cake bake plugin demo model
cake bake plugin demo view

you can bake controllers, models, and views for the “demo” plug-in. The parameters you can use are the same as when baking “normal” controllers, models, and views, for example

cake bake plugin demo controller users

bakes a UsersController with var $scaffold set. See Faster baking of controllers with the bake shell script or Baking views for more details.

One thing you have to be aware of is that the generated controllers and models extend AppController resp. AppModel by default, and not the plug-in-specific versions, i.e. DemoAppController resp. DemoAppModel in the “demo” plug-in example. That means you have to manually change this if you want to make use of the plug-in-specific AppController resp. AppModel.

Happy baking :)

cake bake model User
cake bake controller Users scaffold
cake bake view Users

For more details on those shortcuts call the bake script with the help parameter like:

cake bake model help

or have a look at Faster baking of controllers with the bake shell script and Baking views.

Recently, a new shortcut was added which makes the aforementioned shortcuts (almost) obsolete. With the “all” parameter it is now possible to bake with one command a model plus the corresponding controller with its views:

cake bake all  // asks you for the model name
cake bake all User

This feature is currently only available in the development branch, but the next release is probably not that far away…

Happy baking :)

As I didn’t understood what his script did nor how to use it, Travis explained it in the following way:

It [the bash completion script] gives you bash completion (through hitting tab) for shells and for the bake it gives you bake actions and will autocomplete potential model/view/controller names.

Here’s an intro to bash_completion: http://www.debian-administration.org/articles/316

So,
after I source this (`. bashcompletion`, `source bashcompletion`, or link it in the right location -> /etc/bash_completion.d/) I can type

`(path to console)/cake [tab][tab]`

and it lists the potential shells to use e.g. acl, api, bake (even app-specific shells)

`/cake b[tab]` -> completes 'bake'

`/cake bake m[tab]` -> completes 'model'

If I further do

`/cake bake model M[tab][tab]` it'll complete for models beginning with 'M'

It’s pretty crude atm — doesn’t handle -app params (you can invoke the console within the custom app dir for now).

If bake.php/shell is enhanced to support public, noninteractive listing this could be pretty sweet.

The bash completion provided by this script when using the CakePHP console is really handy. Thanks Travis!

Similar to baking a controller you can now specify the controller for which you want to bake views:

cake bake view Users

This will generate views for all actions in the specified controller (for delete() actions no view is generated).

If you want to bake only a single view, you can specify which view to bake with:

cake bake view Users index

This will generate the index view for the UsersController.

In both cases, bake uses the templates in /cake/console/libs/templates/views to generate the views. You can now override those templates or even define your own templates by creating view files in /app/vendors/shells/templates/views or in /vendors/shells/templates/views. For example, if you want to create a template for “info” views, you would have to create the file “info.ctp” in one of the aforementioned folders.

The statement to generate a view by using a certain template is imho a bit illogical:

cake bake view Users info index

This statement creates the “index” view by using the “info” template. I think it would be more logical if it would be the other way around…

Anyway, happy baking :)

In the aforementioned article I described that you could use the following statement to bake a controller:

cake bake controller

From this statement the next logical step is to provide a way to define the name of a controller via command line:

cake bake controller Users

This command will generate the following controller:

// app/controllers/users_controller.php
class UsersController extends AppController {
    var $name = 'Users';
    var $scaffold;
}

This may be useful in certain cases, but usually you want to bake the actions, too. To allow that, you have to provide the “scaffold” keyword after the controller name:

cake bake controller Users scaffold

This generates the UsersController with the default implementations for the actions add(), delete(), edit(), index(), and view().

By adding the “admin” keyword, you can also generate the admin functions admin_add(), admin_delete(), admin_edit(), admin_index(), and admin_view():

cake bake controller Users scaffold admin

To generate only the admin functions you have to provide “null” instead of “scaffold”:

cake bake controller Users null admin

I like those shortcuts, they make the baking process a much better experience (I don’t like the question-driven approach). For models there are no such shortcuts available yet, but I am sure they come soon.

Happy baking :)

(thanks to gwoo for his short introduction)

Btw: If you have trouble with setting up the console, have a look at the respective screencasts.

cake bake

When using this command you will get this dialog:

[M]odel
[V]iew
[C]ontroller
What would you like to Bake? (M/V/C)

If you know what to bake, this dialog is rather bothering. Fortunately, it is now possible to skip this dialog by providing the type of what you want to bake directly on the command line:

cake bake controller  // for baking a controller
cake bake model  // for baking a model
cake bake view  // for baking views

Even with this shortcut there are still many questions you have to answer during the baking process…

This tutorial shows you how to jumpstart your CakePHP application using scaffolding and Bake. You will also learn the ins and outs of using CakePHP’s Access Control Lists (ACLs). You’ll get a look at what scaffolding is and what it provides. Then you’ll learn how to use Bake to generate the code for a scaffold, letting you tweak it as you go. Finally, you will learn about ACLs: what they are, how to create them, and how to use them in your application.

Like the first part it is a comprehensive and good tutorial. You can also download it as a PDF (without registration).

See also part 1 (PDF)

The AppTask creates the application skeleton. The usage is:

php bake2.php app alias /path_to_app_dir

It does almost the same as:

php bake.php -project /path_to_app_dir

The differences are:

• bake2 doesn’t ask you any questions
• you can define an application alias

The idea of the application alias is to make it easier to work with multiple applications. So you can use just the alias to refer to a specific application. The alias/application mapping is stored in apps.ini, in the root folder of your cake installation.

After the AppTask you will usually execute the DbconfigTask to create the database configuration. This task allows a lot of parameters, but most of them are optional. Here is its usage:

php bake2.php dbconfig alias database username [password] [-c=config name] [-d=database driver]
                                               [-persistent] [-h=host[:port]] [-p=prefix]

That’s it. Feedback and bug reports are welcome :)

The following call:

php bake2.php sqlscripts users profiles profiles_users

creates app/config/sql/create.sql:

CREATE TABLE users (
  id INT(11) NOT NULL AUTO_INCREMENT,
  created DATETIME,
  modified DATETIME,
  PRIMARY KEY (id)
); 

CREATE TABLE profiles (
  id INT(11) NOT NULL AUTO_INCREMENT,
  created DATETIME,
  modified DATETIME,
  PRIMARY KEY (id)
); 

CREATE TABLE profiles_users (
  profile_id INT(11) NOT NULL,
  user_id INT(11) NOT NULL,
  PRIMARY KEY (profile_id, user_id)
);

and app/config/sql/drop.sql:

DROP TABLE IF EXISTS users;

DROP TABLE IF EXISTS profiles;

DROP TABLE IF EXISTS profiles_users;

That’s it. You can find the code in the download section. Happy baking :)