Hello,
I noticed some design errors in the view (view.inc file) class which could be easily fixed. I would like to help you to get a better design of this class, since it's the most important in your module.
You have some factory methods in this class which are, basically, static methods, I think you should implement them in another class, dedicated to the factory pattern implementation, these methods are (I might be missing some of them):
- function &load($arg, $reset = FALSE)
- function load_views()
- save()
The reason why I volontary put the save() method here is if your view objet has not the responsability of loading itself, then it would be quite logical that it does not have the responsability to save itself. This has other reasons than pure logic, by impleting both the load and save factory method in the same factory class, a internal static cache would be easier to handle (refresh or clear some pieces of the static cache when saving a view, for example).
This particular factory class could implemented in another class (i.e. view_factory for example), this would give you some advantages:
- Code in view.inc would be smaller, thus easier to read and navigate into (generally more understandable);
- By separating the factory from the object itself, you then could implement the factory as a singleton if you want;
- The factory could carry a lot of other factory methods without disturbing the view class itself
In all case, if you implement static factory method, please keep the "static" keyword before the function signature in the objets, by statically calling instance methods on objets, you will either generate PHP warning (if the method does not use the $this pseudo variable), either have PHP fatal errors (is the $this peudo variable is used in the local method context).
Notice that statically called methods were in the past (may be untrue anymore, since PHP evolve a lot, but it may be actually be true on a lot of servers which uses older versions) faster than running instance methods.
If you don't want to use the 'static' keyword because you are afraid to loose backward PHP 4 compatibilty, then you can implement the factory as a singleton, and instanciate the objet in a function of views.module which could be like this:
function views_get_factory() {
static $factory;
if (!isset($factory)) {
$factory = new view_factory();
}
return $factory;
}
$my_view = views_get_factory()->load("my_view_name");
Which is the singleton pattern implementation using a procedural PHP function.
Comments
Comment #1
dawehner.
Comment #2
pounardDo you need help for implementation? If you also have other hard architectural choices or some design questions arround, I can help. I don't have much time to write code, but I could use my brain and my experience to help you to give a fresh new start to views 3.
I propose you this because we are a lot of people making a really extensive use of views, and the step between views 2 and 3 (and between D6 and D7) should be the right moment to break some backward compatibilities with others modules and give a fresh new skin to this module to make it really better, for everyone!
Comment #3
dawehnerI just don't see a reason why this should be a bug report :)
I'm wondering why
should be easier/better to use then
The problem with such OOP-Patterns is that it's harder to read the sourcecode, but i don't have a really oppinion about it.
It would be cool one day, if really constructors would be used.
Comment #4
pounardThe bug report is not about the way to get back the view, the bug report is about the factory method inside the view object itself!
In this particular case, it would make view's code easier to read by separating the factory logic from the view object logic itself.
Comment #5
merlinofchaos commentedSorry, this is an area of Views' design that changing will cause far more problems (i.e, upgrades of hundreds of thousands of existing systems that could all potentially be using this public API) than it would solve.
In fact, it doesn't solve any actual problems.
Comment #6
pounardThis is just a cleaner design, and I propose this change for views 3, which is actually not ready for production, so shouldn't have thousands of installed systems.
EDIT: It does not resolve any problems right now, but I'm quite sure that using this kind of pattern would make the views module more maintanable, with more code encapsulation.
Comment #7
pounardActually, they are made to solve common problems, and the more you use known design patterns (and document it), the more your code become maintainable and understandable (as long as you use it wisely).
Using a factory pattern, you should either use the static keyword, either use the methods on a factory singleton (which is not a views class itself).
Statically call instance method will generate E_STRICT messages.
From http://php.net/manual/en/language.oop5.static.php
Calling non-static methods statically generates an E_STRICT level warning.May the Paamayim Nekudotayim be with you!
Comment #8
dawehnerThe last bit is fixed on views for drupal7.
Comment #9
pounardDid a small audit of the code based on D6 version, I did NOT know the last one.
Comment #10
jide commentedSubscribe.
Agreed with pounard on this, especially concerning the views::load_views() method, even the php doc mentions "Static factory method".