A bit of "framework philosophy"

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!

Well said! I think zii should be described as "an official library of commonly used Yii components (extensions)".

As you said, zii components belong to the application domain. That’s also one of the main reasons we are maintaining it under a separate project. And you may also notice that zii component classes are not autoloaded.

We could have released zii separately from yii, and we did have this plan when zii first came out. We ended up "embedding" zii within yii mainly because we expect most people would need both yii and zii, and we want to save their trouble. Still, in the future, if zii grows significantly bigger, we will offer separate releases.

There are also some components in yii that belong to application domain, such as CLinkPager, CAutoComplete, etc. We plan to clean these things up in probably version 1.2 or 2.0.

@mindplay: Thanks for articulating the seed of a thought that has been growing in the back of my mind as I use Yii. Your considered, well-structured post has really helped clear my mind - the application stack ‘features’ included with Yii were starting to muddy up my thought processes. Sometimes, I am so embedded in my own project that when something like CGridView comes up in one of the generated views I feel like I should be using it, and trying to make that module do something that I might be better off writing from scratch.

@qiang: Great response. This sort of attitude gives me the security of knowing that I’ll be happy to keep using Yii well into the future.

I’m very pleased to see how well the project lead received this post - to tell you the truth, I was a little nervous about overstepping my boundaries :wink:

So as long as we’re on the subject - another thing you might want to consider, is a formal component submission and review process. I submitted a component myself a while back - I submitted it as an “issue” in the bugtracker, since there is no formal way to submit components to be considered for inclusion in Yii or Zii. I never got a response - it looks like it was deleted.

Well, you already have the extension submission page. You might want to just add a checkbox there to say, please consider my extension for inclusion in Yii or Zii.

The component I submitted is a file download component, which solves all of the common problems with downloading files from PHP, including memory and other performance issues, support for HTTP resume, and multithreaded downloads - it’s very reliable and general-purpose. If you can let me know how to submit this for review, I would be happy to contribute this component.

Yeah, the process of adopting community-contributed code is a bit vague at the moment.

In general, we prefer you submit your components to our extension repository first. This will allow us to make a better judgment at how popular the components are. It also helps to improve the quality of the components before they are included in our formal releases. Note that once we include the components in the releases, we are committed to maintain them.

I’m sorry that I haven’t really got time to examine your submitted component yet (I do remember it though since I usually will take a quick look at every submitted ticket to estimate the urgency of it.)

No problem - I will submit it as an extension.

The problem with getting people to use a class like this, is to get them to realize that it’s necessary - most developers will make do with a simple readfile() or something similar, not realizing that this comes with all sorts of problems for their end-users.

This class has been used in production on at least 10 different sites over the past 5-6 years.

Anyway, we’ll see what the community makes of it :slight_smile: