When I roam around the open Internet I sometimes find myself in front of nasty surprises. No, I don't mean what you think... I see code written so badly which, despite the author's best intentions, manages to somehow introduce more problems than the single problem it tried to tackle. One such case was a set of patches regarding alternative layouts about to make it in Joomla! 1.6. Since the author of the patch doesn't get the damage caused, I'll take the challenge to explain it.

When I roam around the open Internet I sometimes find myself in front of nasty surprises. No, I don't mean what you think... I see code written so badly which, despite the author's best intentions, manages to somehow introduce more problems than the single problem it tried to tackle. One such case was a set of patches regarding alternative layouts about to make it in Joomla! 1.6. Since the author of the patch doesn't get the damage caused, I'll take the challenge to explain it.

Obviously whoever decided to write that patch has not a single developer bone in him/her. Any developer, even a semi-knowledgable one, would tell you that this is the road to oblivion. It is common for developers to write different layouts on the same view to accommodate for different tasks in order to avoid views proliferation and scope fragmentation of associated models.

For example, we may have a view=checkout with tasks named billinginformation, overview and payment. Each of them, obviously, needs a different layout as it has to accommodate for different data display and input needs. Having one view per task would be a silly mistake, as the model code would be triplicated among those three similar views.

With that patch applied it is extremely easy for someone to create a menu link to the billinginformation task with the overview layout. What a great way to break a site! Then, whose fault will it be? The component developer's for not making enough checks against stupid design decisions in the framework? The user who is oblivious to what he has done? Or, maybe, Joomla!'s for having a framework which doesn't make any sense at all?

This kind of sloppy development transgressing the very essence of how the software is supposed to work and the thoughtful design choices made by the great minds behind 1.5 manages to transform the Joomla! framework from a solid PHP web application platform to a mess of broken core functionality. I understand that the author tried to duplicate K2's multiple layout feature, but the patches fail miserably to fulfil their desired objective. If you take a look at K2, it doesn't allow you to override arbitrary layouts. It treats a set of layouts as a singular "theme". The name of the layout files is cast in stone (it MUST be, as it is the developer's responsibility to assign them!) but effectively allows you to choose the source directory where they can be found.

I really wonder why a member of the Bug Squad takes this kind of framework design decisions despite being an established developer and without consulting the Architect of the 1.6 release (Louis). I strongly suggest that should anyone want to duplicate this features of K2 in com_content (or other components for that matter), first take a look at K2's code and figure out how these guys are doing that without violating the framework with such design atrocities.

I strongly agree that users should have the choice to use different sub-templates, assignable per menu item. However, dear framework, do not allow them to change the view-task-layout relationship I've busted my bottom to develop, test and document. If you really want to do that, allow them to assign arbitrary view-model-controller triads as well. This way they can certainly screw up the component in ways never thought possible. No other CMS has given that kind of "screw your site" liberty ever in the past. Let's be the first to allow that.

Enough said. Some things should never be touched by non-developers, even if they have co-authored the official book on using the CMS. There is a reason why developers develop, designers design, testers test and documentors document...