Object Oriented Blog System Class Structure

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: Object Oriented Blog System Class Structure

Post by alex.barylski »

I rarely provide designers access to any API, only a native PHP result/array. There is no need for a designer to wrap a selectAll() method in two distinct methods such as selectFeatureProducts() and selectHottestProducts(). You would simply use the same module/component but provide different configuration, and possibly a template if the output was drastically different. In these cases simple template inheritence is often enough.

I personally find providing/offering a API in the template layer results in more headaches than whats it's worth.

Cheers,
Alex
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: Object Oriented Blog System Class Structure

Post by josh »

:offtopic: PS > I don't understand 50% of your post? "simple template inheritance"? I think this thread is officially crashed.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: Object Oriented Blog System Class Structure

Post by alex.barylski »

Some template engines, Twig/Smarty support template inheritence. I'm not sure how that all played into the topic at hand, I wrote that at work several hours ago with limited time. :p

My point (I think) was I rarely need (nor would our designers) to provide an API to template designers. Native arrays work best and provide most flexibility across the board (in terms of supporting the most template engines) and ease of adoption among developers.

With a HMVC (complex views/layouts in Zend parlance?) architecture, I have never found the need to provide templates with anything but generic PHP arrays, which almost all template engines support to some degree or another.

Cheers,
Alex
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: Object Oriented Blog System Class Structure

Post by josh »

Eh, that's why I said its a matter of preference. Software is all about a whole bunch of rules that were made to be broken. Its just not good to break them until you are really experienced. My preference for example is to not allow my designs to change my HTML. They shouldn't be all up in my code like that, they've got CSS. So that would be my preference, is to pass the whole object to the template, and kick the designers out of that file. HTML isn't a design language - CSS is.

Even if your designer insists on using HTML wrong, an array is arguably just as hard for them to use as an object would be. Its a matter of preference. That HMVC stuff you're talking about is implemented in ZF by it's "action view helper" I believe. I think its a bunch of nonsense and results in bloated in apps, thats my opinion though. A controller action is supposed to respond to a user action/request. Not an internal API call. (again just my opinion or interpretation of the original MVC pattern)
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: Object Oriented Blog System Class Structure

Post by alex.barylski »

They shouldn't be all up in my code like that, they've got CSS
That wouldn't fly in the CMS market. Any CMS that relies solely on CSS for theming will find themselves in a epic battle wih designers who 'want' more control. Besides, IMO, a good designer is likely to be more familiar with proper semantic XHTML/HTML5 than a developer. At least I prefer to out-source XHTML/CSS stuff, so I tend to seek out people who meet those requirements.

Although I can understand where your coming from. If you building the software and handling the XHTML/CSS then using PHP alternative syntax templates and querying the model directly might make more sense, though it's not nessecary with an HMVC architecture, it's still a technique that accomplishes the same effect.
Even if your designer insists on using HTML wrong, an array is arguably just as hard for them to use as an object would be. Its a matter of preference. That HMVC stuff you're talking about is implemented in ZF by it's "action view helper" I believe. I think its a bunch of nonsense and results in bloated in apps, thats my opinion though. A controller action is supposed to respond to a user action/request. Not an internal API call. (again just my opinion or interpretation of the original MVC pattern)
Any array, honestly man, is what 95% of designers ask for, in every company I've worked for. Querying a model on an object requires resolving the $this pointer somehow, designers with only a basic understanding of PHP often use the wrong operator(s) and find the syntax confusing. Not to mention, passing arguments (if any) causes all sorts of headaches at the templater layer.

The results of a method (as opposed to an array) are also more prone to cause issues, especially when the template engine doesn't support variable assignment and cannot dump the results of function calls.

All I can say, without a doubt, is once I switched to the practice of 100% HTML seperation (not even a tiny "<b>" in outputting text) and removed *requirements* on using methods (of course I still wanted that functionality - by default I pass the results as an array) I stopped getting suggestions/complaints from customers. :)

Different software, different customers, different requirements I suppose.

Cheers,
Alex
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: Object Oriented Blog System Class Structure

Post by josh »

PCSpectra wrote:Different software, different customers
Right, essentially different preferences. Like I said 10 posts back ;-) I've been saying that each method has pros and cons. I think Christopher hates the array method more than I do, but we both dislike it, you on the other hand and probably lots of CMS developers prefer the array method and hate the object method. Different preferences. If CSS were more mature, possibly you'd have different preferences.
User avatar
Jonah Bron
DevNet Master
Posts: 2764
Joined: Thu Mar 15, 2007 6:28 pm
Location: Redding, California

Re: Object Oriented Blog System Class Structure

Post by Jonah Bron »

An interesting discussion indeed.

I've been reading Understanding MVC in PHP by Joe Stump on O'Reilly (http://oreilly.com/pub/a/php/archive/mvc-intro.html). I now have a 90% complete framework. It's pretty cool, everything is so neat and modular. Still working...

Cheers.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: Object Oriented Blog System Class Structure

Post by alex.barylski »

Right, essentially different preferences. Like I said 10 posts back I've been saying that each method has pros and cons. I think Christopher hates the array method more than I do, but we both dislike it, you on the other hand and probably lots of CMS developers prefer the array method and hate the object method. Different preferences. If CSS were more mature, possibly you'd have different preferences.
I think you may have taken my comments to literally. I wasn't implying, it's a matter of preferance or requirement, nor whether arrays or methods are better or worse, I was just saying, that in my case, when working with clients and CMS, the array, IMO, is often the better choice because of the requirements. I fully understand those requirements do not apply to 100% of the cases.
I've been reading Understanding MVC in PHP by Joe Stump on O'Reilly (http://oreilly.com/pub/a/php/archive/mvc-intro.html). I now have a 90% complete framework. It's pretty cool, everything is so neat and modular. Still working...
Post it when your done so I can leech any good ideas :p

Be prepared for harsh judgement though, frameworks are not easy and everyone has an opinion.

Cheers,
Alex
User avatar
Jonah Bron
DevNet Master
Posts: 2764
Joined: Thu Mar 15, 2007 6:28 pm
Location: Redding, California

Re: Object Oriented Blog System Class Structure

Post by Jonah Bron »

*braces self*

Pretty much finished. Just bare bones, no template engine integrated (yet?).

There is a variable called $data in the mother Module class, and it holds all information that is passed to the template. At least, that's how the article I've been reading has it setup... Before being sent to the template, it's converted to a stdObject.

To Do:
- Complete /includes/Object/Web.php
- Complete /includes/Object/DB.php
- Other stuff?
User avatar
Jonah Bron
DevNet Master
Posts: 2764
Joined: Thu Mar 15, 2007 6:28 pm
Location: Redding, California

Re: Object Oriented Blog System Class Structure

Post by Jonah Bron »

*braces self*

Pretty much finished. Just bare bones, no template engine integrated (yet?).

There is a variable called $data in the mother Module class, and it holds all information that is passed to the template. At least, that's how the article I've been reading has it setup... Before being sent to the template, it's converted to a stdObject.

To Do:
- Complete /includes/Object/Web.php
- Complete /includes/Object/DB.php
- Other stuff?

Framework tar
blog-0.6.tar.bz2
(5.84 KiB) Downloaded 170 times
I'm using SVN, PHPDoc (for the first time) and PEAR Codesniffer (also a first) using the Wordpress standards. I was going to use Zend, but it was too picky about the Doc header comments :|
Last edited by Jonah Bron on Wed Sep 08, 2010 12:51 pm, edited 4 times in total.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: Object Oriented Blog System Class Structure

Post by alex.barylski »

Nice clean coding style, fairly consistent, I like that.

1. arrayToObject() if memory serves me corrrectly you might be able to achieve the same thing by simply doing:

$object = (object)$array;

Might be the other way around, try it and see. :P

2. library\controller.php is handling your routing and dispatching, which go hand in hand but should be separate distinct objects.

Code: Select all

$module = BL_DEFAULT_MODULE;
$module = isset($blUrl[0]) ? $blUrl[0] : null;
Whats the point of reassigning, shouldn't BL_DEFAULT_MODULE be the default instead of null???

Also from a quick glance I cannot see anywhere that actually dispatches to an variable number of actions, instead it seems, your dispatcher, calls the same action everytime and the view is determined based on a $view variable???

Cheers,
Alex
User avatar
Jonah Bron
DevNet Master
Posts: 2764
Joined: Thu Mar 15, 2007 6:28 pm
Location: Redding, California

Re: Object Oriented Blog System Class Structure

Post by Jonah Bron »

PCSpectra wrote: 1. arrayToObject() if memory serves me corrrectly you might be able to achieve the same thing by simply doing:

$object = (object)$array;

Might be the other way around, try it and see. :P
I tested it, and unfortunately it's not recursive.
PCSpectra wrote:2. library\controller.php is handling your routing and dispatching, which go hand in hand but should be separate distinct objects.
I'm not clear on that; could you give a quick explanation of how those could be seperated?
PCSpectra wrote:Whats the point of reassigning, shouldn't BL_DEFAULT_MODULE be the default instead of null???
Fixed :mrgreen:
PCSpectra wrote: Also from a quick glance I cannot see anywhere that actually dispatches to an variable number of actions, instead it seems, your dispatcher, calls the same action everytime and the view is determined based on a $view variable???
$_GET['passed'] is provided by the Apache mod_urlrewrite, and it contains anything after the root of the URL. As a standard in my application, the first item in the URL is the module to load. Everything after that is passed to the module as a string, and it can do what it wants with it. My reason for this is to give more flexibility to the module. The view is defined by an actual GET parameter. That way, everything normally is shown with the default view, but a different view can be specified (for example calling with Ajax and requesting the data to be sent as JSON instead of normal HTML).

Perhaps this is just unnecessary unconventionality?

Edit: updated the tar
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: Object Oriented Blog System Class Structure

Post by josh »

PCSpectra wrote: which go hand in hand but should be separate distinct objects.
Matter of opinion again ;-) My rule of thumb I stole from Christopher. Split a big class into multiple smaller ones when it becomes unmanageable. If that class is simple then its generally ok to have a class handling multiple related responsibilities.

Also see: http://en.wikipedia.org/wiki/Single_res ... _principle

None of these software "rules" are actually achievable by anyone in real life. They're more like "guidelines". By the way library/controller.php has a high Cyclomatic complexity (not a good thing). Basically another goal is to not nest your if statements/loops too deeply.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: Object Oriented Blog System Class Structure

Post by alex.barylski »

Matter of opinion again My rule of thumb I stole from Christopher. Split a big class into multiple smaller ones when it becomes unmanageable. If that class is simple then its generally ok to have a class handling multiple related responsibilities
I disagree. I mean it's a matter of opinion if you don't care about flexibility. A dispatcher and router can be in the same class, if the framework will only ever be used in a single application with a single dispatch/route requirement.

However, if you ever wanted your framework to support multiple dispatching techniques, such as invoking a object method, static method, procedural function or possibly simple includes, then you would want to have the dispatcher be a pluggable component, seperate from your routing.

Similarly but far more common, is the requirement to change a routing implementation. Do I want something like:

index.php/do/something
module/controller/action/do/something

Alternatively maybe you want a native NVP URI or quite possibly something far more intelligent and flexible, like supporting a WordPress style custom permalink structure, in which case the router is far more complicated.

Keeping the router and dispatcher seperate provides greater extensibility and IMO more accurately adheres to SRP. Two classes with distinct purposes not one God object that handles both routing and dispatching.

Splitting a big class only when they become unmanagable is a good rule of thumb, as it prevents over-engineering. But I also think sticking with a strict DRY KISS policy, and following OCP makes more sense. If you can anticipate that software will need extension points in the future, it is better to design that flexibility at the beginning and extend the class, as opposed to redesign or re-implement a big class only at the time of requirement - thus breaking the OCP.

Personally, I would rather have two distinct classes that are interchangable with other implementations than a slightly more simple implementation in a single class but that is fixed to routing to object methods only and only capable of handling a fixed number of URI structures. If the ease of use of a single class is the appealing part, which i suspect it is for most framework client developers, than provide a facade that gives you a basic default, such as dispatching to object methods and a generic NVP URI structure. That way, controls freaks like me can opt to not use the facade and provide something more custom, but CodeIgnitor type developers can get going yesterday.

I think you may have taken SRP out of context, or at least misunderstood me. I see SRP as keeping distinct functionality in distinct classes, routing and dispatching, are obviously distinct functionalities, so to me, what I explained above is a good example of adhering to SRP.

Cheers,
Alex
User avatar
Jonah Bron
DevNet Master
Posts: 2764
Joined: Thu Mar 15, 2007 6:28 pm
Location: Redding, California

Re: Object Oriented Blog System Class Structure

Post by Jonah Bron »

I still don't see how it could be split into two functions; It seems like one thing... Do you mean figuring out what module & view need to be loaded, and actually loading them?
Post Reply