[samdark]

Currently we have two ways of generating code: yiic shell that's deprecated and Gii. Gii got a very warm welcome and is a really good tool. Still, in some cases it's preferred to use command line.

Problems
- Maintaining templates for these two methods is double amount of work.
- Command line code generation is deprecated but is still used by developers.

Solution
- Same templates for both cli and Gii.
- API to use these templates.
- Gii and cli using API.

[softark]

I never used yiic shell where Gii can offer the alternative.
What do you mean by "Still, in some cases it's preferred to use command line."?

I mean, isn't it enough just to remove those yiic commands that have their equivalents in Gii?

This post has been edited by softark: 07 August 2011 - 10:04 PM

[samdark]

softark
1. Some developers are preferring CLI instead of UI.
2. If you want to re-generate models automatically, for example, at SVN/Git commit hook you'll need either CLI or API.

[Dana]

I prefer to use the CLI for model generation, specifically because it creates the fixture and test data which the Gii tool has not done to date. It would be very troubling to lose that capability.

If there was a way to bring the two together so that they can share templates it would be wonderful.

[softark]

I see.

What about the modifications and/or additions that a developer has made to his customized Gii? Could they still be applicable to CLI?

Templates may be OK, but what if he has modified the UI and added some extra fields to it?

[Say_Ten]

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

[grigori]

the web-based is better due to interactivity
for now it's just showing diff, but with cli you won't get this conveniently

it worth to concentrate on gii and improve the generators

[Raoul]

I use yiic to generate the Yii webapp skeleton (when creating a new project) or start unit test by one click from my Eclipse workspace. I find it convenient ...

[mbi]

I always use yiic

[migajek]

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.


My vote is for yiic

[Maurizio Domba]

Yiic is not deprecated only code generation from command line...

we should differentiate this...

Yiic is still used for creating a new webapp and for various CLI commands...

In the beginning yiic was used to create models and CRUD, too... and that is the part that was deprecated in favor of the more flexible Gii...

So we are talking here only for this part if yiic or did I understood this wrong?

As for me - for the code generation I use Gii... and IMO we can remove the model and crud from yiic... no need to have it doubled as there is no way to offer or possibilities of Gii in yiic...

[yiqing95]

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 .

[jacmoe]

I actually like both.
Would be nice if they could be made to make use of the same templates/code/whatever.

One thing that I'd like to have is a web-based interface to the migrate shell.
Sometimes you don't have shell access on a host.
A web based interface with diff view would be really neat.

[samdark]

mdomba
Yes, we're discussing code generation only.

jacmoe
Check my webshell extension.

[mbi]

I think, while creating a new app it is better to work with yiic.
my initial flow is the following:

• yiic webapp
  
• yiic migrate create install
  
• edit database settings in config/main.php, config/console.php
  
• yiic migrate
  
• yiic shell for creating modules, models and cruds

this is really saving me a lot of time

[migajek]

ok, still voting for yiic for code generation.
Console is just way more convenient.

[Psih]

Like the Gii, so I think they should be merged. Functionality should be the same. Just different interface

[jacmoe]

I totally have that console thing...
CakePHP model/view/crud generation by the command-line is really awful..
No preview either..

I also like Giix instead of Gii.

[Psih]

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.

[jacmoe]

samdark, on 19 August 2011 - 12:20 PM, said:

jacmoe
Check my webshell extension.

You are right.
And I did.

It's actually pretty simple, also without using the webshell extension:

	private function runMigrationTool() {
    	$commandPath = Yii::app()->getBasePath() . DIRECTORY_SEPARATOR . 'commands';
    	$runner = new CConsoleCommandRunner();
    	$runner->addCommands($commandPath);
    	$commandPath = Yii::getFrameworkPath() . DIRECTORY_SEPARATOR . 'cli' . DIRECTORY_SEPARATOR . 'commands';
    	$runner->addCommands($commandPath);
    	$args = array('command', 'yiic', 'migrate', '--interactive=0');
    	$command = $runner->createCommand($args[0]);
    	array_shift($args);
    	ob_start();
    	$runner->run($args);
    	echo htmlentities(ob_get_clean(), null, Yii::app()->charset);
	}

The only problem is that web app doesn't do command map.
Which is needed for the migrate script if I want to use a custom migration class and/or use a table prefix for the migration table.

If a web application could have a command map, I'd be happy.