The Yii team has been generally very good at keeping the codebase free of clutter - and just as importantly, Yii is free from the burden that most frameworks drag around, namely a full “application stack”. Most frameworks don’t make a distinction between “framework” and “application” features, and as a result become more cluttered and in some ways, I think, more daunting to newcomers, with their sheer volume of classes.
One of my favorite things about Yii, as compared to "full stack" frameworks such as Zend, is that Yii only comes with components and architecture that can be rightfully said to be "framework", and not "application".
Of course, it may be hard in some cases to draw an exact line between the two, and I think the first criteria for selecting features that belong in the framework, and not in an application stack, should be:
[i]Is it absolutely general-purpose?
If not, is it fully extensible?[/i]
Certain features, like the URL manager or Active Record, are not absolutely general-purpose. But they are sufficiently general-purpose, in the sense that (almost) everybody is going to need at least the core functionality of those components. And because they are fully extensible, developers can build on top of them, rather than having to replace them, if they find that a component does not fully cover their specific requirements.
The reason why I do not want application features in a framework, is because I know from experience that these will not meet my strict requirements - I will eventually end up replacing these features, and the existing features provided by the framework are reduced to baggage.
Everybody is different - we all have different goals, and even if we share some goals, we usually have different means for reaching those goals.
[b]I believe the reason why we (this community) have converged around a framework, is because we agree on certain practices, and the framework is designed to leverage those practices, in a convenient and standardized way, for us.
The subtle art of the framework is to achieve this, without getting in the way of individuality - to enable us to adhere to the good practices that we agree upon, while still allowing us to be as different, as versatile and as colorful as we can![/b]
Yii is the first framework I’ve known (in my career of 13 years or so) that fully achieves this!
Having said all that, I would like to discuss a couple of "weak" points.
First, Blueprint CSS, which comes with the standard vanilla Yii application.
CSS was designed to help us separate content from layout - but Blueprint requires you to put the layout in the content markup. It abstracts it, sure - but whether you specify the width of an element in pixels, ems, inches or columns, you’re still specifying the width of that element within the markup.
This is one of the more commonly heard criticisms of Blueprint - the heart of the idea, is to encourage (or enforce) something what is by many considered a bad practice.
Even if you agree with the authors of Blueprint, that putting the layout in your markup is acceptable, there are hundreds of ways to do that - Blueprint is not likely to be the choice of the majority of developers who agree with this practice.
On top of that, it’s not really used for any significant purpose in the standard mock-up Yii application - you could do what this entire CSS framework does for the standard app, with two lines of CSS, and it would be a lot more obvious to everyone what those two lines are for, than why they would need this entire framework.
That’s why I do not believe that Blueprint belongs in a framework.
Secondly, the CMenu and CBreadcrumbs components, which come with the user-contributed Zii extensions.
Both of these components failed to do anything I needed. They’re too simple for most real-world applications - at least any of the real-world applications I’ve built.
And their ‘views’ are embedded within the code. In fact, layout/view rendering make up most of the code payload in these components. That is not MVC. And I think we can all agree that MVC is one of the key practices that created our need for Yii in the first place.
Are they at least general-purpose enough that I could extend them? Sure - but all that would be left of them, would be the function prototypes, and the overhead of loading/extending an additional class. There would be no point in extending something that is already this simple.
Plenty of applications don’t even need breadcrumbs or menus - or in my experience, if they require menus, they usually require something a lot more elaborate than a simple, flat menu.
That is why I don’t think these components belong in a framework.
They would feel more at home in an application stack.
In fact, I’m a little blurry on what the real purpose or goal of Zii actually is.
Is it merely to collect user-contributed components in a separate subfolder? That doesn’t seem to solve any practical problem or serve a real purpose.
Or was the real thought behind this to start collecting more general-purpose application features - to build a full application stack?
Things like breadcrumbs and menus certainly fit better into an application stack, than they do in a framework. My own application stack has several such features.
So I would like to encourage you to think about the real role of Zii as it contrasts with that of Yii.
It occurs to me that perhaps Zii does not belong within Yii - that perhaps it should be distributed separately, and should be seen as an optional "application stack" that complements Yii, for those who do not have the time (or will, or stamina) to build or maintain a full stack of their own.
This way, Yii can (eventually) meet the requirements of two audiences: developers like me, who insist on building an application stack that meets their exact requirements - and developers who currently currently choose frameworks like Zend, because it comes with everything (plus a whole fried chicken).
Certain (probably very few) user-contributed components might then make it into the core of Yii, such as for example CTimestampBehavior, which I think is sufficiently general-purpose to be considered part of the framework.
In truth, whether or not a component was written by a user or by the Yii team, has no bearing on it’s purpose, it’s value, or it’s justification - and it’s not very interesting or useful for me to be able to distinguish who the author of a component might be, by looking at it’s parent folder.
So please consider liberating Zii from Yii - and more importantly, consider giving it a real, meaningful purpose!
And once again: great work! Both the Yii team, and everyone who contributed - you’re doing a fantastic job!
Thank you!
