Figuring out a better way to handle template updates

avenger · November 4, 2009, 11:25am

There currently is a discussion going on elsewhere in the forum about the problems involved for shop owners and template developers when the OXID-template needs updating.

(I am currently including the 4.2.0 changes into my (heavily modified) OXID template system, and let me tell you: this is a real pain in the ass… There just [B]must [/B]be a way to make that process easier for everybody…)

I thus believe it would be worthwhile to start a discussion between template developers and OXID-developers on possible ways to alleviate this problem, while maintaining the ability to evolve the product as needed.

And maybe even make it better and more flexible at the same time.

So, everybody feeling competent on that topic and believes he’s got some ideas to contribute to help achieve the aim, is invited to join in.

Many people [B]must [/B]have thought about this before!

[B]Would an admin pls. make this topic “sticky”, so that it not gets lost over time? THX.[/B]

avenger · November 5, 2009, 5:11am

To start things up, I have 2 pragmatical suggestions…

While converting my template to 4.2.0 I found some templates utilizing more or less identical code, but which are to be maintained separately:

[B]details.tpl[/B] and [B]details_persparam.tpl[/B]
[B]account_user.tpl[/B] and [B]user.tpl[/B].

[B]details.tpl[/B] and [B]details_persparam.tpl[/B]

The only difference between the two seems to be the “persparam” input field

So, [B]details_persparam.tpl[/B] can be modified to:

[{include file="details.tpl" show_persparam=true}]

And in “[B]details.tpl[/B]” the code for the “persparam”-field has to be inserted at the proper location

                        [{if $show_persparam}]
            <div class="persparam">
                <label>[{ oxmultilang ident="DETAILS_LABEL" }]</label><input type="text" name="persparam[Beschriftung]" value="[{ $product->aPersistParam.text }]" size="35">
            </div>
                        [{/if}]

And away goes the bulky “[B]details_persparam.tp[/B]l” as a separately maintained template!!!

[B]account_user.tpl[/B] and [B]user.tpl[/B] share [B]identical [/B]code for the invoice and delivery addresses…

So we extract this common code from both template files into “[B]inc/user_data.tpl[/B]”…

And at the proper places in [B]account_user.tpl[/B] and [B]user.tpl[/B] we replace the existing code with

[{include file="inc/user_data.tpl"}]

And from now on we need to maintain the common bulky code now in “[B]user_data.tpl[/B]” only once!!!

[COLOR=Black]Just found out, that “[B]register.tpl[/B]” apparently could use the same [/COLOR]"[B]inc/user_data.tpl[/B]" also…

Also, a couple of redundant language definitions could go away…

avenger · November 11, 2009, 11:23am

No comment from OXID development???

marco.steinhaeuser · November 12, 2009, 12:34am

Hi,

[QUOTE=avenger;18343]No comment from OXID development???[/QUOTE]

Pointed devs on this thread again.

Cheers

alfonsas_cirtautas · November 12, 2009, 8:13am

Short info about [B]details_persparam.tpl[/B] it is only as an example of custom article details tpl feature.

avenger · November 12, 2009, 8:21am

[QUOTE=alfonsas cirtautas;18430]Short info about [B]details_persparam.tpl[/B] it is only as an example of custom article details tpl feature.[/QUOTE]
Might well be, but:

in the 4.2.0 Upgrade docs it is included as to be changed…

Which means, that most people will [B]do [/B]the update.

Unnecessarily, if it would be handled as suggested…

The sugggestions still could serve another purpose very well:

with a small change in the new “[B]details_persparam.tpl” [/B]and "[B]details.tpl[/B]"you could easily handle multiple “[B]details_persparam.tpl[/B]”, if e.g. you should need different names for the persparam field for different products.

Just handover the persparam field description too, when including “details.tpl” from “details_persparam_xx.tpl”

tomas_liubinas · November 12, 2009, 9:22am

Hi avenger,

Thanks for your suggestions. I agree with you. There is definitely some problem with this template. As Alfonsas said this template was originally intended as a DEMO template for product details customization. But again you are absolutely right, it should not be included in template update documentation.

In my opinion the way to go is moving pers param functionality to details.tpl as you suggest. Then, instead of having this template together with all other “normal” templates, we should remove it in order not to confuse people or, especially now when we have “custom” template dir, we can move this template to custom dir.

Anyway FYI I already opened the bug for this problem:
https://bugs.oxid-esales.com/view.php?id=1470

tomas_liubinas · November 12, 2009, 10:04am

And another one:
https://bugs.oxid-esales.com/view.php?id=1471

Just before QA confirms this as a bug I would like to provide some background notes on this topic. Actually as developers we are aware about various places where templates could be optimized. However template changes are quite sensitive issue. As you said for shop owners updating templates is a hell. It means that with every template change which we implement, all existing shop owners have to change them as well. This means thousands of template changes. With this in mind our strategy is to change templates only when it is really necessary and in some cases if we can do a workaround we even prefer leaving templates intact.

Anyway it is really good to hear an opinion of people who work with real designs. So thanks again for this thread.

avenger · November 12, 2009, 10:21am

[QUOTE=tomas liubinas;18437]And another one:
https://bugs.oxid-esales.com/view.php?id=1471

Just before QA confirms this as a bug I would like to provide some background notes on this topic. Actually as developers we are aware about various places where templates could be optimized. However template changes are quite sensitive issue. As you said for shop owners updating templates is a hell. It means that with every template change which we implement, all existing shop owners have to change them as well. This means thousands of template changes. With this in mind our strategy is to change templates only when it is really necessary and in some cases if we can do a workaround we even prefer leaving templates intact.

Anyway it is really good to hear an opinion of people who work with real designs. So thanks again for this thread.[/QUOTE]
That is exactly the reason why I believe, similiar template-code should be there only once!

Today you need to update “account_user”, “register” and “user” if something changes in the user-data in these templates, as was the case with 4.2.0.

So if you combine the user-data-portion of all three templates into one “include” file, this part needs to be changed only once instead of 3 times as it is now.

[B]And [/B]you will have a consitent layout for the user-data area in all templates.

Yes, you would need to update the three templates again, but afterward you will harvest the benefit of doing so, by having to look at only one file to change.

Just to give you my experience with 4.2.0 Template-Updating:

it took me almost a day of very concentrated work to do the update, but still I managed to introduce some mistake every now an then…

The problem ist, that most likely you can’t take the standard-template based update-info, because you modified the template (e.g. moved around or added/deleted some things), so you have to find the place in your template where to apply the code-change to.

So, avoiding any update which can possibly be avoided helps…

Especially when bulky templates like the above mentioned are concerned.

bofh · January 10, 2010, 11:22am

i still dont understand why thers no additional layer.
i mean for most users and for the most common functions you do not need changing the code itself. you need mostly design mods.

so if thers 2 layer for the templates most users will be fine by changing the top level.
onyl special need have to go one level deeper and onyl change a few things and onyl to update a few.

i really do not understand why such a pretty good software doenst have those 2 layers for templates a need such big updates frequetly in the templates.
by the way , you do normaly a tempalte engine to prevent updates in the design when you change the core but…dont ask and dont think … sometime you dont wanna know the answer

avenger · January 10, 2010, 2:16pm

[QUOTE=bofh;22435]i still dont understand why thers no additional layer.
i mean for most users and for the most common functions you do not need changing the code itself. you need mostly design mods.

so if thers 2 layer for the templates most users will be fine by changing the top level.
onyl special need have to go one level deeper and onyl change a few things and onyl to update a few.

i really do not understand why such a pretty good software doenst have those 2 layers for templates a need such big updates frequetly in the templates.
by the way , you do normaly a tempalte engine to prevent updates in the design when you change the core but…dont ask and dont think … sometime you dont wanna know the answer :-)[/QUOTE]
Could you pls. explain, what you mean by “additional layer”???

MaFi · January 11, 2010, 12:47pm

Template are already the 2nd layer.
When there are changes in the code there is no need for changes in the template. I know that in each new version of eShop nearly all templates have changes and this is a PITA. BUT nearly all of this cahnges are optional!!! Usually you do not need to touch your templates when you do an update. Because most of the changes fix some issues with templates OR introduce new functionality. If you don’t want to use these new features (e.g. multi dimensional variants) you do not need to change frontend templates. My experience is that OXID tries to be downward compatible to old templates. Best example here: you can use the 3.X Templates in a 4.X Shop with only a few changes … Nevertheless you need to check all templates included in an update to see if the changes inside are critical. Maybe it would be good if OXID publishes two changesets, one with all template changes and one with the mandatory changes really needed to keep your shop running …

bofh · March 4, 2010, 1:40am

additional layer - i ment inside the templates not additional bevore smarty

at the moment design and smarty methods are mixed up some of them have an seperate inc some not… and i dont wanna talk about the product tpl

ok you reduce the lines of code but its not always about reducing the lines.
for example there should be at least one tpl for each view (with one selector of course)

and as far as possible the smarty functions should be seperated from the design (like avenger started with his template)

i know there will be much more tpl files (a lot more)
there will be much code doubles (not nesseraly much but a bit more)
but most users can make their templates by simple include the function they need in a certain spot
and with the next update you will just update the functions tpl not the design tpls

developers of course have it easier too

bofh · March 4, 2010, 1:52am

btw jsut one thing about product tpl

these constructs like
if its thin then else to something are programmers hell.
sorry just my point of view

okok it saves lines of code but smarty is a simple script oriented so sometimes you have to couble the code to have it clean - the most code will be design code anyway since the functions itself (where we could of course ask if it sthin or not) are seperated and used by all variants of product.tpls