Page 1 of 1

When simple is not sexy

Posted: Sun Oct 18, 2009 4:41 pm
by alex.barylski
Title get your attention? :P

I've been following a debate over at Sitepoint about Zend and it's bloat. While I agree Zend is over-engineered I would also suggest that CodeIgnitor is not any better, being to simplistic.

I am trying to think of examples where 'simple' is a bad idea:

1. Adding that last SQL query to a template just to get the project finished, as opposed to taking the time to add an additional model method or refactoring an existing one.

2. Using globals! sure they make development a little faster during initial implementation but they make maintenance a potential nightmare.

Cheers,
Alex

Re: When simple is not sexy

Posted: Mon Oct 19, 2009 12:16 am
by josh
When someone releases a plugin architecture that is inherently doomed for failure http://joshribakoff.com/?p=81
Using singletons 'in the wrong context'
hard coding multiple SQL queries that only vary with eachother by a parameter or two
duplicating code to avoid any indirection
having blocks of code in loops & conditionals instead of using polymorphism or extracting methods
business logic in in the view files ( I should be able to do $product->getPrice() without 1,000 extra lines of code doing extra calculations )
Creating "sub-modules" or subpackages when the code is not specific to any specific module (trying to avoid creating too many packages, but at the cost of each package being harder to understand)

Re: When simple is not sexy

Posted: Mon Oct 19, 2009 1:04 pm
by Jenk
Over-developed visitor pattern is my pain at the moment.

Other idioms are things like:

Code: Select all

if ( ($x > 3 && $x < 9) || ($x == 0)) {
instead of:

Code: Select all

if ($this->isValid($x)) {
or:

Code: Select all

$found = false;
foreach ($foo in $bar) {
  if ($foo == "foo") { $found = true; }
}
 
if ($found) { echo "foo found!"; }
instead of:

Code: Select all

if ($this->containsFoo($bar)) { echo "foo found!"; }

Re: When simple is not sexy

Posted: Mon Oct 19, 2009 3:51 pm
by alex.barylski
josh: Good points - thanks :)

jenk: I like that first example, excellent case of 'easy to write, hard to read and therefore modify'.

I wish more took both 'reading' and 'writing' of code into consideration when implementing anything. If they did, I am sure all those easy 'hacks' you find in code would not exist. At least to the extent they do now.

As much as I favor Zend over code ignitor, I do find it's controller implementation way way over engineered. Perhaps my own are missing some crucial functionality but I would be surprise if my front and base controllers counted more than 100 lines.

So while Zend is at least geared towards good design, I fail to see how simplicity in design escaped them. ugh.

My intention is not to turn this into another Zend VS XXX framework I am not even venting at the moment, just sharing. :) Please don't get offended if your form either CI of ZF camps :)

Cheers,
Alex

Re: When simple is not sexy

Posted: Tue Oct 20, 2009 2:14 am
by josh
Well keep in mind they have routes, a plugin architecture, etc..

Re: When simple is not sexy

Posted: Tue Oct 20, 2009 4:32 pm
by alex.barylski
Not sure I follow, what was routes and a plugin architecture? Zend controllers?

You can acocmplish the same extensibility with my own framework, only routing is something done outside the context of a front controller. I'm not sure what you mean by plugin architecture in this conversation though, can you exaplin a little better maybe i'll learn something about Zend controllers :)

Cheers,
Alex

Re: When simple is not sexy

Posted: Wed Oct 21, 2009 4:17 am
by josh
If you have utility methods on different controllers you need to use.

Like if you have a regular user & premium user controller. Later you decide to write an admin controller that needs methods on both, but due to their inheritance hierarchies its impossible. The plugin broker is basically like a system that sits inside of your __call method and allows you to use "helper" classes.

There's a lot that can go into the plugin system. I have heard developers give speeches on why using a plugin system is so foolish, yet the huge community of developers taking advantage of it don't care about leaving these people behind.

Re: When simple is not sexy

Posted: Wed Oct 21, 2009 11:29 am
by alex.barylski
Hmmm...interesting...although I don't think I would encounter any issues like that, as my controllers are not typically reusable like that.

I started following that extreme chain of thought "thin controllers-fat models" zealously and it's resulted in very dumb controllers, anything I needed in controller A might possibly inherited from controller B, but it would be something trivial, like providing a base controller to initialize a complex view, which all derived controllers would then tweak according to their context (such as setting title, etc).

Anything authentication or anything else for that matter would be stored in a model, which would be equally accessible from any controller.

Re: When simple is not sexy

Posted: Wed Oct 21, 2009 1:25 pm
by josh
An example of useful plugin is one that inflects the name of the module/controller/action and checks an ACL table, and redirects the user to a login page
or one that maps request parameters to arguments of the action method.
etc...

Re: When simple is not sexy

Posted: Wed Oct 21, 2009 1:38 pm
by alex.barylski
By controller plugins you mean, like a front controller and intercepting filters - or do you mean each controller has additional pre and post action execution plugins.

I have use a pre-filter plugin to achieve basic authentication before, thus avoiding using a base controller to perform the checks and possible security hole introduced by failing to derive a controller from the proper superclass.
or one that maps request parameters to arguments of the action method.
My framework only supports system wide intercepting filters (pre and post). They are executed before and after each action invocation. So parsing a URI and initialing the request object with NVP, at this point, wouldn`t make much sense, at least it could be done more effectively in other places, in my setup anyways.

In any case, I think I understand what you mean by plugin architecture now, fairly standard with most MVC frameworks. :)

Just slightly different implementations.

Now I am actually curious though, how does a controller support pre and post plugins, in addition to the system wide intercepting filters -- do you derive from a base controller which provides this additional functionality. I have though about doing something like that in times past but could never think of a scenario where the problems are not better solved else where.

Cheers,
Alex

Re: When simple is not sexy

Posted: Thu Oct 22, 2009 4:48 am
by josh
Usually there is a plugin interface you implement with your plugin, or an abstract plugin base class that provides blank implementation for each method ( so you implement only the method you are interested in)

The plugins just need to be observers of the events, whatever object has an instance of an event broker should be able to notify all the plugins at events regardless of where they are called. But when you say system wide events I think that could be a bad term, events are like variables in the sense that you probably want to scope /type them. Like a domain specific event like a user adding an item to his cart, should be an entirely different subsystem then a front controller plugin. Supposedly there are some really involved event patterns, some people use the concept of event "channels" which would work similar to exception bubbling