The destiny of YII 1.0

While Yii 1.1 release is good, it looks like bugfixes

from 1.1 didn’t affect 1.0 version. Does anyone know

when it’ll be possible to have fixed 1.0?

Are there any particular things you want in 1.0?

Well, yes.

I mainly use Yii 1.0 as a basement. It’s light and simple.

On top of it there is an extensions layer inheriting from

the core.

In the project I don’t use ActiveRecord and have QueryBuilder

built on top of DAO. This way, I don’t use common GUI tools

as well (since most stuff is tightly bound to AR). This makes

project run much faster and requires less memory/resources.

Also, database layer looks much simpler comparing to AR-based.

I’d gladly share ideas I have and would like to contribute

with QueryBuilder / CSS-framework development. Let me know

if this makes any sense.

Your approach makes sense. In terms of DAO 1.1 is almost the same except some features. Is there any particular reason to use 1.0 instead of 1.1?

Contributions are always welcome.

In fact, Yii 1.0 is just simpler and I was surprised not to

see 1.1 bugfixes in 1.0. Yii 1.1 contains overcomplicated

GUI layer. Presentation layer in YII isn’t solid and obliges

us to rely on ActiveRecord. I’m sure it’s not something users

would appreciate. On the other hand, it’s too late to change

things in the core. So, this might be an extension library.

One more reason in favor of 1.0 is that we shrink the core

before publishing to omit things that aren’t used: cli,

console, ar, oci, mssql, i18n/data, i18n/gettext, markdown,

html purifier, text highlighter, messages, core views & etc.

This way, our installation bundle gets under 2mb compressed

with all bells and whistles including exe ftp installer.

I’ve just tried to shrink 1.1 and the footprint wasn’t much

bigger comparing to 1.0.

Regarding my contribution I’d gladly discuss this via skype.

Before start it’s required to define module architecture and

I’m pretty sure Quiang has great ideas on this point.

If you mean CGridView, CListView and so on, these are not core components but a part of zii. Noone forces you to use them. You can totally shrink them as you did with 1.0.

What do you mean by define module architecture?

I know core doesn’t depend on zii. What I really mean is:

CHtml is a helper class for Html. As a programmer I expect

this would be a tiny file with most common functionality, but:

  • It’s huge because contains form rendering functions

  • It’s not generic by supporting form rendering

  • It’s forcing me to use CModel

So, why not break it onto CForm & CHtml?

Or even better: delegate form rendering to CFormWidget.


So, my view of DB / GUI design might be changed in the following


  • GUI doesn’t depend on ActiveRecord.

  • CHtml only contains generic functions.

  • SqlMapper or Service to build DB-independant queries.

CModel is not ActiveRecord. You can use CHtml form helpers with and CModel superclass. For example, CFormModel.


I know CModel is not an ActiveRecord, but YII’s CSort depennds on CActiveRecord.

This is what I mean. What I need is DB-independant DB layer based on builder

pattern and GUI components that will work for form/grid/list having no idea of

what AR is.[/s]

Sorry, my fault. CSort references CActiveRecord but doesn’t require to use it! :)

No, CSort and CPagination don’t depend on AR either, and this has been so since 1.0.

Yes, but…

Sorry, my fault. I was missed out by seeing no abstraction between classes.

I’ve read through the code and found out that while having CActiveRecord

references in the code, it’s possible to omit $modelClass.