Several features which are critical for practical work

in any case the number of ways cannot be more than 5

at least 1-2 of them should be automated somehow

ideally it should be a way that allows the most possible integration of DB with third party search engine like Solr

that’s the general sense of my request

How SOLR is connected to i18n?

I mean in case if you will implement automation of this feature, you should choose in these 5 possible ways the way that allows maximal simplicity for indexing with third party search engines

I give you practical requirements, certainly all of them relate to each other

  1. As I remember this validator

http://code.google.com/p/yii/source/browse/tags/1.1.7/framework/validators/CEmailValidator.php

during the latest 2 years works incorrectly

I think you know that currently domain names can be in ANY language.

And custom top level domains allowed.

So the only rule for validating e-mails is probably only presence of @

But I’m not sure, I did not read RFC.

You should analyze this question and fix all accordingly.

  1. PhoneValidator would be helpful too
  1. About your practice to include Js code inside PHP code.

I met some places inside the framework.

From my point of view it is rather bad style.

What is your official position?

The problem is that many stupid coders who will see this inside the framework will begin to do it in GIANT amounts inside the application with an argument "See this? It is allowed!"

You should include an official note about this style into your coding practices guide.

  1. About your coding style

I don’t know where you found such style where all is written into single line without any space

$message=$this->message!==null?$this->message:Yii::t…

but it is terribly non-readable!

absolutely!

the worst problem is that coders see this **** inside framework and begin to write in the same style

you give the very bad example

you should fix your coding style standards

  1. $reverse attribute should be added into CExistValidator

It is useful for cases when we need to show customized message instead of db error on unique constraint in "login" field for example

$reverse option will allow to use this validator for contrary purpose = to thow validation error if some value exists

Take a look at CUniqueValidator.

  1. it would be useful to connect CUserIdentity and CWebUser with models, to allow access model’s attributes as CWebUser properties
  1. Create one new level of logging = "audit"

On this level all CRUD operations for all models classes (except log itself) should be logged with user()->id/login/name and datetime, name of operation, recordId and model class name

Such feature is required ion many applications by default.

Certainly complex applications require such logging on business logic level.

But for many simple applications or first versions of complex applications require the described functionality will be absolutely enough.

  1. it should be built into CActiveRecord
  1. Built-in and documented (!) features for autogeneration "on the fly" of model classes based on db tables.
  1. CButtonColumn needs beforeDelete()

and if it returns false the row should not disappear

I can appreciate your effort on putting this huge list but consider this is a framework and the core need to stay small and anything that application specific or can turn into extension or module should be consider first.

The whole Yii download the last I check is about 4MB which is quite big for a framework in my mind.

  1. It is possible and very very easy to make customized builds "on request" for the framework core.

  2. I hope that some of my requests can be implemented by extensions developers (even in case if these extensions will be paid) if they cannot be included into the framework core.

[color=#1C2837][size=2]"customized builds" usually equate to "lot of works" on each new release to patch in the "custom" stuff.[/size][/color]

I mean the very basic implementation of custom builds

just look at sections in chm guide, and you’ll see that 25%-50% describe features that can be easily removed from the very basic core

  1. customizable builds as described above

  2. dependency checker

too big distr is the problem in my current project and it takes too much time to check dependencies manually

some automatic built-in dependency checker (which allows to remove completely unused files from Yii) would be VERRRY useful

  1. explanation

why big distr is a problem?

certainly it is zipped

but each mass downloadable product should consider that many shared hostings do not allow some these

  • unzipping of files by webserver

  • running as php scripts all unzipped files created by webserver during unzipping

  • SSH access that allows unzip all manually

it means the following

distr should be unzipped locally and uploaded file by file by FTP

the current project contains many thousands files - so such uploading may be a verrrrrrrrrrrrrrrry long process