Ok so this is just to ask from the guru’s out there when, how and why you’d use a component. For example looking at the default components made, I understand that main menu is a widget setup for displaying the main menu. But then you have the user identity which is used to control user access with login authentication.
Reading the guide, you get the hint that a component is an object to handle specific public variables and events. As to what that implies exactly I’m a little confused.
I think from what I understand, component is like free for all in which you can define different things for your site specifically. Example, lets say you wanted to create your own rule sets (for password strength, capitalizing the first letter on names, valid postal code / zip code w/e). You would create these "functions" within a component and then use that component as a reference. Am I close?
Any shade of light on the subject would be great .
It is best to extend main component class whenever you need to create application-wide (or global, if you wish) functions connected to the main application class.
Let’s say, for generating seo-friendly urls.
If you are about to check password strength in several actions, handling input format from a single point, then you definitely should implement them as a component.
As a developer, you may already know that there is no exact definition of application structure. Put your code in semantic ways so that it fits your needs.
Generally, I don’t extend CComponent if it isn’t needed (and use static functions mainly) in order to maximize reusability and performance.
Almost any class you use in Yii can usefully be a Component. It adds “magic” gets and set, and the ability to use Yii’s behaviours and event handlers, which are potentially powerful things.
Almost everything in Yii is already a Component, and so I’d say that unless there are good reasons for a class not to be a Component, then make it one.
Agreed, I just built a calendar application as a component for the framework, but because of this it’s still reusable as a normal class for free standing php. It’s in the tips and snippets section.
I don’t understand this approach. If you have a class that has getters and setters, then why not subclass it from CComponent? Job done for free; no code written. And, if you later decide to use your class as a Widget or anything else down the Yii object chain, then your class is already Yii’ified.
Also, static methods (that take a parameter) can be a symptom of the feature envy code smell. It’s an interesting exercise to take some legacy code (of a non-trivial application) and remove its static methods – where they aren’t really static – and watch the cascade of simplification that occurs.
Imo, There is no correlation between statics and improved reusability; I’d argue the opposite.
I’d definitely argue that performance is worse with overuse of statics. But then I regard performance issues as something entirely separate and a post development issue, and I’d rather concentrate on good quality maintainable code than an early focus on performance when it might never be needed.
Let’s have a look at CHtml, as it only has static methods and only a few properties. It definitely is tied into the system, once you have implemented your flexible views.
You may say it doesn’t extend CComponent because its functions is not application-specific. If so, what about CHtml::$afterRequiredLabel? Seems like a very useful, yet static feature to me.
A method being static doesn’t fundamentally mean it is reusable or faster. It means you don’t have to initialize a copy of the given class to use static methods.
I have a Urlize class in order to automate link generations in many cases. What would be the point of ‘new Urlize;’? I prefer using Urlize::accountUrl() instead.
Totally agree. I’d add that performance is worse with overuse of setter/getter methods as well.
If you are curious, dig a bit in Yii internal source code to find out that Qiang avoided to rely on getter methods and used the original method directly (like CActiveRecord::getIsNewRecord()).
So I’ll go further. Performance is worse with overuse of classes at all.
Yes, I could use global functions. Still, it’s more convenient for me to use static methods instead of component getters whenever possible.
First off, I’m not wilfully disagreeing with you, pestaa. I see how you help the Yii community and I have a lot of time for you because of that. We’re on the same team.
To answer your question, it depends, but that’s why I qualified my answer; I know I’m talking to informed people.
I know what a static method is and what it entails. I use static methods as an interview question. I even tell interviewees that I will be asking them about static methods. It’s not going to help anyone who hasn’t been using them for years
There are plenty of cases for static methods. Any Singleton getInstance(), for example. I’m not “against” statics, they have their place, but they mustn’t be overused.
It all depends. But until there is a performance issue, I genuinely don’t care.
I step through Qiang’s code routinely. I don’t agree with all his choices. He’s good, but I’ve worked with better.
In any system I refactor, the first thing I do is remove globals.
Correct. Because of this, I didn’t mean to offend you in any way. But our common boat doesn’t mean we cannot have healthy discussions, right?
I was sure you know what a static method is, just mentioned it as a reason why I choose them instead of component getters in many cases.
I didn’t say I create static helpers for every bit of function that crosses my mind. I said I generally avoid extending huge base classes, if the other way feels more natural to me.
Deeply discussing this would lead to off-topic, so would you be so kind to send me a pm mentioning a few points you disagree with?
You probably guessed I agree with this. We write 2009.
No offence taken, and healthy debate is always good; it’s great to learn. Glad to hear you’re not a static-junky – I didn’t think so. It actually got me thinking about Yii’s AR model() function, which was at the back of mind to examine. But it seems its just a way of avoiding multiple static methods by instantiating its own object just for AR purposes, which is cool. See my PM for OT stuff.
Very good discussion indeed. I don’t like static classes (e.g. CHtml) either. While static classes are easy to use, they are more difficult to be extended and customized.
It might look bad idea to define find methods as non-static in ar models at first sight, since they have nothing to do with the current database row, but if you think about chainable, short and easy-to-maintain selection, you thank model() for its existence.
[quote name=‘qiang’]static classes […] are more difficult to be extended and customized.
[/quote]
It depends I think. It is easier for me to extend a static class with many protected properties than it is to customize non-static class with no or private attributes.
.