As LightPress stabilizes, we can start asking ourselves a few questions on its architecture, some of which Jerome and I have already discussed in private. Given the increasing interest in LightPress, I thought it better to move the development discussions here, to give readers the opportunity to influence our decisions.
The question I've been meditating this weekend is whether the current Frontend class is trying to do too many things at once, and if it would be better to split it into separate classes. I'm not trying to start a religious discussion on design patterns, OO vs functional programming, or leaky abstractions, I'm just wondering what (if) we would gain/lose from splitting Frontend into more manageable/consistent classes.
If you are not familiar with Frontend, you may notice by looking at this rough UML diagram that its methods are already split into categories:
-
the constructor and context methods, which set up the instance and its operating parameters (are we dealing with a post, an archive page, etc.)
-
the getSomething methods that access the DB connector and return data
-
the renderSomething methods that manipulate the Template engine and render data
-
utility methods
The class seems to suggest a split into three parts:
-
a model which holds the reference to the DB connector and hosts the getSomething methods
-
a view which holds the reference to the Template engine and hosts the renderSomething methods
-
a controller, basically the current Frontend stripped of the above methods, that holds references to the model and view, sets up the running context, and deals with options, messages, plugins, etc.
The main benefits I see with this approach are
-
simplifying unit tests, as the setups required will be much less complex
-
an increased modularization which might enable us to swap the default view with one, say, using no template engine or a different one like Smarty
The main drawbacks are for plugins and plugin authors, unless the controller class has proxy methods for the model and view methods (bleah!). What do you think?
If anybody is reading this, I have thought a bit more about this issue while in a meeting (even meetings have a practical purpose sometimes…), but have no time right now.
It has to do with the contet-type Frontend argument Jerome and I have discussed in the past, and specialized models/views based on it (eg specialized model/view for feeds, for Google sitemaps, etc.).
Later…
I think the doing to much problem takes you down the path of replicating the do everything in index.php problem that alread is the bane of WP to some extent yes?
I just found lightpress this weekend and haven't even grabbed the code yet. Once I finish putting way.nu back together again, I'll probably give it a shot. The advantage you have right now is that you don't have that many users who will be impacted by a refactoring.
You might want to kick some ideas around with this guy.
Jonathan,
If you need help/tips setting up LightPress just give us a shout. We're still working on that 5-minute install… :)
Ludo,
Not sure I like the proposed split, it feels too much like an attempt to fit MVC without a solid justification for it. The best solution should be the simplest, reducing both code and complexity if possible.
What if Frontend was pruned down by using specialization: a base Frontend class for the basics, subclassed by context/function perhaps? You could have a specialized feeds version for instance. Or one for search contexts.
Jonathan, our index.php is just a few lines, everything is managed in a few classes, which helps encapsulating and dividing complexity.
What I am wondering is if our base class (Frontend) is becoming too complex. Even though its methods follow a naming convention which clearly define their purpose (i.e. getPosts() renderPosts() etc.), splitting this class may have a few advantages, mainly:
- modularity (which lets you do different things by extending a base class or one of its methods)
- less user-visible files (managing feeds with two diferent model/view classes instead of having a feed.php file)
Jerome, it's exactly what you are saying in your last paragraph above, except that instead of subclassing Frontend, we subclass View/Models. Frontend would be a single class dealing with:
- options checking
- internationalization
- plugin management
- context set-up
- choosing the appropriate view/model pair based on the content type (i.e. (x)html, rss/atom, siteindex, etc. — we could even have a pdf version LOL)
- invoke the appropriate model/view methods (which may contain a simple return() statement, e.g. getComments() in the sitemap model/view)
The last three make Frontend the controller, since it sets up the context and content-type which define what data is served by the model, and how it is displayed by the view.
The more I think about this architecture, the more I like it. There are a few problems though, mainly with object references (what to pass and when to pass it), and plugins.
Yes, IMHO splitting it up is a good thing. The name and scope of the class, make it seem a bit like a God-class. I don't think I can weigh in on the question along which lines to plit it up, thoug, since I have to little familiarity with the code. Are you guys familiar/reading in the Sitepoint.com PHP Design forum? There are some very capable people and questions like this are regularly discussed. They are a bit MVC-heavy, but there's still a wide variety of people to get some balanced advise.
Sencer, I have the same god-like class impression about Frontend :) My experience with OO is that smaller and with a more defined perimeter is better (up to a point ofc).
I'm starting to miss Python packages/imports/__init__.py :)
I have opened a dev branch to investigate the issues above, since I think we might better decide what to do if we have some code and a running example. It will take some time, but if you are interested you can follow (and comment) the progress on the ludo_mvc CVS branch (cvsview on sf is a few hours behind the repository, so you won't see much for some time).