Just wanted to tell you, that I have converted my template for version 4.2.0 to use the “template override”-feature.
It works like a charm!
I have separated the template like follows:
everything [B]but [/B]
css, button-graphics, box-header-graphics and any graphics specific to a user template, [B]plus[/B] my central structure-definition template “_index.tpl” and my template configuration files
went into the [B]main [/B]template, the a.m. items into the “[B]override[/B]” template…
I also tested overriding one of my “box”-templates (which is necessary now and then if a customer wants a different layout) by copying it into the “override” template-structure, and it [B]really [/B]has taken precedence over the one in the main template!
Very nice indeed!
This feature will help [B]a lot [/B]in getting a better organisation within the template-system, so that you need to maintain the vast majority of the template files for [B]all [/B]your customers’ templates [B]only once[/B]!
But, at the same time, still preserving the necessary flexibility to support [B]any [/B]thinkable designs…
[B]So one big issue for me with OXID templating is resolved![/B]
Technically speaking the underlying template files for our first OXID 4 CE customer shop at http://www.digital-readers.de/ has become [B]my(!)[/B] standard-template now, it has got all the hooks and bells and whistles I will need to create all other shop designs we will do.
From experience with xtcommerce (where I use my own template overriding) typical candidates for overriding will be the css-files, “product.tpl”, “details.tpl” (maybe some “boxes” now and then) and my “[B]_index.tpl[/B]” for defining the overall shop structure.
So you can achieve [B]any [/B]shop design and layout rather elegantly…
And, what is at least as important, it is [B]maintainable [/B]even for a large customer base…
The template overriding is really a big advance.
(As a matter of fact, if it were not supported now in the shop core, I would have done it myself (like in xtcommerce)!)