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?
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
way:
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.
[s]Samdark,
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.