I believe Gii is easier to use than yiic code generator by people new to the framework. I don’t see the point in maintaining two code bases that does exactly the same thing. yiic will still be a part of yii i think as it generates the webapp and message translations and i do not see those functionalities in yiic code generator.
However, I don’t think it would be bad idea to phase yiic code generator out all together in favour of gii and keep all code generation in one place. Yii framework could then be distributed with a skeleton application instead of generating one.
Gii offers things that yiic cannot like side by side comparison of files when you are about to overwrite a file, code preview etc…
May i ask what kind of things you inspect and try with gii?
In my project I have a custom URL Manager which makes it very difficult to use Gii. In order to do it I have to temporarily disable the custom URL Manager and turn on Gii-specific URL rules. Therefore for me yiic shell is very helpful.
I am sad to hear that the intention is to drop yiic shell. As I thought the idea was only to deprecate code-generation in yiic shell, but not yiic shell altogether.
Granted that many people who would prefer Graphical UI; However, for me, along with like-minded individuals, yiic shell is so useful, and far superior.
For example, in yiic shell I can run arbitrary php code, within Yii framework, where I have full access to Yii functionality and data. I can create objects, do adhoc database insertions/updates/…etc, test all functionality, like url creation, message translation, and many others.
From the technical point of view, there is no strict need to develop two independent pieces of code. The common functionality of yiic shell can be isolated in a library/classes which can be used by both Gii and yiic shell.
Last and not least, I come from RoR background, I can’t imagine living without ./script/console . Which does essentially what yiic shell do.
I wish Yii developers reconsider that direction.
Yii is by far one of the best frameworks ever, yiic shell represents an important element in Yii awesomeness.
I agree with Kefah, yiic is vital to some applications to make tests, inserts on database, etc, to some users a write a word on a terminal seems more natural that do alot of clicks, and he did a great propose to isolate the yiic classes to be used on both applications.
Yes, the code generation part should remain to have 1st grade support on the yiic shell.
But, in addition to that, all yiic shell should also enjoy 1st grade care.
I am not stating that in a demand attitude, as Yii is a free software and every one is invited to help; including myself. I mainly stressing the importance (strategic-wise) of keeping and maintaining a fully capable yii interactive shell.
I got back to learning the Yii Framework a couple weeks ago. The reason I started using it in the first place was because it had yiic shell, it’s an amazing tool. Imho, deprecating it would be like deprecating Terminal.app on OS X, or the Unix command-line on Ubuntu.
I also agree with Kefah:
I would go even further than that by saying that yiic shell should be the main script to maintain and Gii only a GUI front-end for yiic shell.
One last thing: Imho, the greatest advantage of a command-line tool over a GUI tool is speed. It’s much faster to work on the command-line. The way I see it, yii is the most lightweight PHP RAD framework and deprecating its command line tool would take away its RAD aspect.
I think that generating CRUD for composite keys is more useful than rewriting the way of generating code. Sincerely, don’t understand why Qiang and Yii team don’t include support for CRUD in tables with composite keys, because this kind of table is present in all professional applications and it is what the ER modeling states.
Till now, we have to declare a fake autoincrement pk instead of a composite primary key and create an unnecessary index in the table just to keep the integrity. I’m sorry, but this is workaround that real database professionals shouldn’t agree with and certainly avoid. However, to write all the CRUD code manually is a pain in the neck.
So, imho, the way you generate code is not so important, the generated code is the most important thing. And the generated code in Yii has been improved so much with CGridView, why not implementing the composite key support instead of rewriting all the generation code structure?
It’s not my intention to create a flameware, neither to make ofensive comments, so, please, consider my post as a simple point of view that i have been stating for some time to make even better a framework that is one of the best.