I entirely approve of this suggestion. I haven't used the CLI in a while as we went with the fluffier system for consistency all round. I would like to see it brought up in terms of quality though as it's sometimes easier to work in for us command line commandos ;p

Hi,
I was very disappointed when first saw "yiic" is deprecated.
I think nobody will argue that most of php developers use console anyway (for server maintenance etc).
As for me, console is more convenient, it's faster to type than to click and type, and is easier to extend (I'm using yiic shell for running my own commands for technical maintenance of php service - dropping cache, and so on).
Also, yiic is zero-configuration and doesn't need to be disabled after deployment.

i often use gii ，even develop our own templates . but as samdark said the cli sometime is more useful to developer. we can write php or other language scripts to communicate with the cli , for example auto generate all CRUD controller and views for all models . you see someone is so lazy .

when develop application we should support both GUI and CLI interfaces to end client . GUI is for human beings, CLI is for program , these two interfaces should share the logic and data access layers. so the solutions samdark give is well. they can use api which is a intermediate layer to share the templates thus to reduce maintenance costs .

Have to agree on Giix - it's far better (still has it's issues with the code quality - some undefined variables warnings and other stuff - will be fixing it and providing patches - but the functionality is good ).

The WEB part is great, especially the ability to preview what is actually generated and select the files you want (sometimes I need 1 or 2 files from CRUD generator, not all of them).

And what I really want, is ability to use some DB specific features like checking the box "Use MySQL specific features" witch will understand "ENUM" type fields and actually generate a rule like

array('field', 'in', 'range' => array('ENUM1', 'ENUM2, ..., 'ENUMN')

or date type fields.
That should be build-in from the start, but optional. Need one? Tick the checkbox (and maybe be able to define defaults in config).
I had a discussion with SamDark about adding DB specific code generating to Gii and the reasoning for not doing it is solid - we provide cross-db functionality. Totally understand the reason. But the reality is - how many people really write cross-db code? Some, yes. But not majority. So I think there has to be db specific code generation in Gii - just optional, not enabled by default (unless done in config). People will use it, and they will be happy for sure. And I'm 100% sure community will fill in the gaps with patches quite fast for every supported DB.