Several features which are critical for practical work

1. Interesting use case.

  1. There are some in extensions. Have you reviewed these?

  2. It’s very project-specific so unless all your projects are structured the same way you’ll need different set of rules to apply. There are Phing and Ant doing exactly this. We’re using Phing to manage Yii release process. Also it can be done via simple plain PHP-script.

  3. See #3.

5. What do you need findDirectories for? By deleteDirectory you mean recursive directory deletion?

  1. Don’t think we should have it in the core since it’s application-specific. Here’s third-party implementation: https://github.com/firstrow/yiiadmin

  2. I think the right way is to have another CFormModel class.

8. What for? Current findFiles works for directories too.

  1. See #6.

  2. Application-specific + there are behaviors in extension section for doing it.

  3. Application-specific + generally application shouldn’t change DB schema.

  4. Application-specific.

  5. See extensions section + Zend_Mail.

  6. See extensions section for various file uploader wrappers.

  7. Don’t think it should be in the core framework since there are actually only a few products where interactive installation needed compared to websites and other projects. Moreover the ones I know already have their own vision to this process.

  8. Application-specific.

  9. Application-specific.

  10. See extensions.

19. There is CWebLogRoute. It doesn’t color messages though. Any idea what should be colored and how?

  1. Please elaborate.

  2. Application-specific.

  3. Application-specific.

23. Why YUI and not another one?

  1. Application-specific.

to Samdark:

12, 16, 17, 18, 21, 22, 24

In fact each complex feature can be called "Application specific"

All jQueryUi and all ExtJs can be called "it is application specific…" - but these libraries exist.

30%-50% of existing features in Yii can be called so.

I just mentioned things that will simplify life significantly for a lot of people.

So it is just wish/decision of framework developers whether they want to spend their time for it or not.

Other items are commented below.

==================================

  1. Not yet.

(This list is built only after writing the specification for my new project and memories from the 2 latest.)

a) I did not find a method that automatically can run migrations from non-console application, and needed to examine core files for writing one.

It would be better to add such method into framework.

  1. What do you need findDirectories for?

= now for building distr and zipping all, including empty directories

By deleteDirectory you mean recursive directory deletion?

= yes

6,9 will review later and tell my opinion

  1. it looks you did not understand,

I’m talking about CHtml::active* controls that generate id-s && names based on model class name

  1. It does not.

See code from this class

			if($isFile)


				$list[]=$path;


			else if($level)


				$list=array_merge($list,self::findFilesRecursive($path,$base.'/'.$file,$fileTypes,$exclude,$level-1));
  1. Application-specific + generally application shouldn’t change DB schema.

= nobody cares what it should not, a client just want to do it

  1. See extensions section for various file uploader wrappers.

= file uploads are not the main problem

buttons and links are

not sure how all is done now, I’ll review and answer later

  1. This problem is not mine.

One former developer in Clevertech told that it is difficult to analyze debug logs for him, that’s why I remembered it and mentioned it.

  1. Why YUI and not another one?

= I read articles that it was called "the best" in some comparison with other compressors

  1. In fact I did it in old version of CRM in Clevertech

See moneyMask plugin that I used in this project.

I need something like this.

In fact it is better to ask financial people about how they want to see it implemented.

Additional note about the term "Application specific".

Understanding of this term is very very very wide.

In fact it depends on how you position Yii framework on the market.

In case if you position it as framework for "websites development", yes, you are right.

But if we will begin to talk about "web-based products (!) development", you are incorrect. The most part of features that I listed are required exactly for "web based products". A typical website definitely can live and survive without them.

So, it is global question in fact. The question that concerns strategy of your framework development for the several next years.

For "web-based products" all these features are not even "not application specific"…

For "web-based products" all these features are obligatory!

By the way… this dilemma "web-based product OR website" was in fact the main reason of conflict in the company where me and Samdark worked.

The most part of people who began a new development branch developed all in the style of "website development".

What does it mean?

Maybe you don’t know one fact, but I read that the most part of websites are never gradually upgraded… they are completely rewritten from the scratch! because it is simpler to do so…

But I preferred to keep development in the style of "web-based product development", in the way that supports extension, multiple use and unlimited number of versions and upgrades.

  1. One more feature request.

Sometimes it is very useful to create a common base model class for pre-processing of features which are common for all models.

Now for doing it I need to customize view which is used by framework for auto-generation of models and add there such things for passing rules and relations to ActiveRecord which extends CActiveRecord




		return parent::rules(array(

<?php foreach($rules as $rule): ?>

			<?php echo $rule.",\n"; ?>

<?php endforeach; ?>

			// The following rule is used by search().

			// Please remove those attributes that should not be searched.

			array('<?php echo implode(', ', array_keys($columns)); ?>', 'safe', 'on'=>'search'),

		));






		return parent::relations (array(

<?php foreach($relations as $name=>$relation): ?>

			<?php echo "'$name' => $relation,\n"; ?>

<?php endforeach; ?>

		));



Also I need to write a LOT of code for performing such feature pseudo deletion.

And one more note.

You should not insert this into each autogenerated model.




	public static function model ($className=__CLASS__)

	{

		return parent::model($className);

	}



You can just do in core class the following




	public static function model ($className=__CLASS__)

	{

		$className = get_called_class ();

		return parent::model($className);

	}



CONCLUSION: you should consider the fact that some developers in some projects will create common base model class which is direct child of CActiveRecord;

and even if you will not implement some things for simplifying this work, you should at least avoid creating of things that may require deep rewritings in this situation

KamilRafik

Custom Gii templates is the way to go. That’s why it supports custom templates.

About models, get_called_class is a PHP 5.3+ feature. Yii 1.1 works on PHP 5.1.0+ Moreover there is no way to solve the following situation with this code: Post::model(‘Comment’)->….

By the way…

Why you decided to go with graphic tools like Gii and made command-line tools (which are usually more appreciated by Unix/Linux community) deprecated?

Where is the logic?

  1. CConsoleApplication needs "user" property (either CWebUser, or maybe you need to create CConsoleUser and inherit CWebUser and CConsoleUser from CUser)

SENSE: there are many console tasks that should operate with the same db as published in web and perform all actions in the context of some user account

KamilRafik

yiic and yiic shell aren’t deprecated. What’s deprecated is only code generation using yiic shell. Decision was due to a lot of errors when typing and no good way to both make it easy, interactive and customizable (with console apps you need to remember all these switches and stuff, while when using GUI it’s all there).

  1. You can add it via config.

btw., just remembered about executing migrations from GUI. I’ve created a web wrapper for yiic some time ago: http://www.yiiframework.com/extension/webshell/. It does exactly that — executes yiic commands from web context.

> 26. You can add it via config.

Yes, I know.

All things that I ask here, I DID already, or at least I know how to do them.

Here I just ask to add them into the framework by default (!), for a case if framework authors did not think about them and will agree with me.

Well, the problem is that these defaults will not be necessary for every possible use… and in fact will not fit most of the projects (these are typically websites, not applications). Moreover, changing defaults will break compatibility for sure. That’s not desired to do in regular releases.

Regarding #26 specifically… this one is backwards compatible and probably a good idea.

Anyway, I’ll review this list again for sure… just need some time to think about all these features and changes.

OK.

I understand. I don’t pay for it. All in the list is just my wishes.

I just will continue to add into this topic all ideas that will come into my head.

Maybe some of them will be implemented by other people as extensions, or even extensions paid for commercial use.

It would be great too.

  1. For CModel I need

getErrorsString() and getErrorsList()

why?

the current getErrors() returns nested array

it is rather non-comfortable to dump it into log or output into some simplified error message UI

  1. Mass deletion methods in AR like deleteAll() etc. should invoke events like afterDelete and beforeDelete that will contain in parameters ID-s of all deleted records.

The same events generation should be done for all mass operations with data - not only for deletion.

I don’t think it’s CModel’s responsibility to provide different data structures for different presentational purposes. I’d rather extend CVarDumper and CHtml for that.

  1. You need more correct migrations handling for websites which have content in different languages stored in several db-s with names db_en, db_fr etc.

a) you should automatically apply migrations to all dbs

B) migrations table autocreation and filling should be done correctly

  1. Also I think for this situation you should automatically provide some id-s synchronization between identical tables in different db-s

For each new record in one db identical record must be created in all other db-s

With validation etc.

The same for all CRUD operations.

A) This isn’t common to store multi-language content in different DBs.

B) Please elaborate.

  1. It’s totally depends on your way to store multi-language content. I think there’s no common solution.

there are 2 ways to store multilanguage content

  • in different dbs

  • in different columns

in any way a good framework should automate the process of CRUD operations depending on a global setting

we should not operate with such things like db_en etc. or title_en etc in the second case.

we should operate with "db", "title"

all language management and auto-selection of correct column/db should be done on db level depending on CDbConnection options

you have not now automation for any of ways

Also you can store it:

  • In differently prefixed tables such as post_en, post_de.

  • In the same table (with extra column "language").

I believe there are more ways I’m not aware of.