• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

I'd like to define new view skin for just view, but would like to fall back to another skin for all other scripts (edit, rdiff, search etc). With Cairo it was possible to do that. With Dakar you get strange results. For example, if you define a new skin with just one view.testing.tmpl file you get:

  • search reporting a template error with missing %SPLIT%
  • rdiff showing just a %TEXT%

To reproduce this, create a view.testing.tmpl with this content:

Start of =testing= skin to test skin fallback
-----
%TEXT%
%META{"form"}%
%META{"attachments"}%
-----
End of =testing= skin

Activate this skin as the default in Main.TWikiPreferences, with fallback to pattern: Set SKIN = testing,pattern

Go to any search page and diff to see the issues.

The problem is because the pattern and classic skin include the view template in the rdiff template. TWiki falls back properly to pattern for rdiff, but rdiff in turn includes the testing view template instead of the pattern view template.

A proper fix is to prefix the first skin found to the skin list, and use that in all subsequent template includes.

I found this issue while upgrading a site from Cairo to Dakar. Dakar behaved strangly with the custom skin of that site.

This took me a while to debug.

-- PTh

Fixed in DEVELOP, rev 9311, 9311, 9313. This should go into the next patch release if it is tested enough. I did some testing and could not find any issues.

This is not merged into TWiki-4. I am confused on the Current State. Should this be set to Closed or?

-- PTh

I am very concerned that this fix adds yet more complexity to the already complex process for resolving what template gets loaded. Before it can go into the patch it requires very careful and thorough documentation, and ideally a testcase or two.

I'm having real trouble getting my head round your fix. Surely a proper fix is to fix the templates so that the view template is not included in the rdiff template? Or to have view and rdiff templates each include a common template that allows them to share? Pattern skin is overcomplex in the way it includes other top level templates. I tried to think how you would explain your fix to a user, and found it very difficult....

(P.S. urgent fixes should be done on the TWikiRelease04x00 branch and then merged to DEVELOP. Only use DEVELOP when you are doing something that must not be merged to TWikiRelease04x00)

CC

Agreed, it is a complex problem. The easiest way was the fix I did. Also agreed, the pattern and classic skins could be fixed to not depend on view (the classic skin has the same dependency, introduced in Dakar). In earlier TWiki releases, the skins have been simpler, just one shared twiki.xxx.tmpl for the skins's view, rdiff, search...

NOTE: I am not yet setup for multibranch dev, I have too many things going on to worry about this. I'd appreciate if someone could merge this into TWiki4.

I am still not clear at what point to close the item: Close at fix in DEVELOP, or close at time of fix in DEVELOP and TWiki4.

-- PTh

I'm going to revert 9311 -> 9313 in DEVELOP branch

SVN 9389

and fix the templates in TWikiRelease04x00

SVN 9391

CC

It is unfortunate that templates in DEVELOP and TWiki4 are going out of sync now. Better to look at the real (perceived) problems.

You say you want to have a new skin for view, but pattern (or another skin) for other pages. Surely rdiff is not a view page. Of course rdiff looks like pattern, this is what you wanted. (and recent rdiff.pattern.tmpl does not include view, but page instead).

search is another cup of tea. This template includes view, otherwise search stops working. It might be better to copy view.pattern.tmpl in search, but code duplication is also not good. It is extremely difficult to write a skin for search: there are many pages where the template is invoked, and a small change in the template may break any one of them. It would be better if search wouldn't need those SPLIT tags.

As far as I know, only search.pattern.tmpl would need to have an explicit include:

%TMPL:INCLUDE{"view.pattern"}%

AC

Arthur, the only time an include has to be qualified with the skin name is when there is potential ambiguity as to which template might be picked up. I qualified all includes as a prophylactic measure, but you are welcome to regard it as overkill. The problem that Peter encountered was caused by pattern skin including a top-level template from a lower-level template, when that top-level template had been overridden by another skin.

Anyway, the technical detail. There are two INCLUDE models under debate here.

The first model is "include by rule", and is the current implementation. Under this model, an INCLUDE is always taken from the first skin on the path that provides that template. This is the model described in the documentation.

The second model is "include by implication", and is the change Peter has proposed. Under this model, the skin path is dynamically modified so that the skin that the most recently included template was taken from is pushed to the front of the skin path.

So, let's consider what happens when we have three templates, A, B, and C. A includes B, and B includes C. Assume that all includes are done using "%TMPL:INCLUDE{"A"}%" i.e. with no skin qualification. We assume that A.tmpl, BN.tmpl and C.tmpl are all defined.

We also have skinone, that defines A.skinone.tmpl and C.skinone.tmpl.

Now, we define a second skin, skintwo, that defines C.skintwo.tmpl, and we set the skin path to "skintwo, skinone".

Consider what happens under the two models. Under the "include by rule model", A.skinone.tmpl includes B.tmpl, which includes C.skintwo.tmpl. This is because the template to be included is always found by searching the skin path from the first skin to the last.

This is clean, and simple for skin authors to get their heads round, and is fundamental to the concept of skin paths.

Now consider what happens under the "include by implication" method. A.skinone.tmpl includes B.tmpl, which includes C.skinone.tmpl! Hang on a minute; my skin path was "skintwo,skinone", and C.skintwo.tmpl exists! Why is it including C.skinone.tmpl instead?

You might manage to convince yourself that "include by implication" is sensible until you start looking at different scenarios. Consider what happens when B.skinone.tmpl exists, but A.skinone.tmpl doesn't. When A is instantiated, and includes B, it will pick up B.skinone.tmpl. But B.skinone.tmpl incudes "C". Which C? C.tmpl or C.skinone.tmpl? Well, A.tmpl was the first template included, so logically it should be C.tmpl. Or should it be C.skinone.tmpl, which was the first template picked up from a named skin?

If it isn't obvious to me, god help a newbie skin author.

I fully accept that either scheme will work. The problem I have is that the "include by implication" scheme seems horrendously complex and counter-intuitive to me as soon as you move beyond the most trivial include scheme. The current implementation is bad enough at nerd factor 4, but the change I reverted took it up beyond 7.

Oh, and please don't try and tell me it is more compatible with Cairo, because it isn't. Cairo didn't have skin paths, so this question never arose.

CC

AC and ML both correctly pointed out that the explicit include by template name introduced an unacceptable level of inflexibility, so I reverted the change and only explicitly named the top level templates (e.g. view, edit etc) that may overridden in the way Peter describes.

SVN 9520, 9521

CC

For anyone (read, probably only me) who is overriding viewleftbar, you need to TMP:INCLUDE viewleftbar.pattern or your leftbar will disappear. There's probably a fix, but I'll leave it with this note.

  • I have tested an override, and the leftbar shows up find. Use Set COVER = bitca, or Set SKIN = bitca, pattern. Replace with your own skin name for bitca. -- AC

ML

Closed with the release of 4.0.2

KJL

ItemTemplate
Summary Skin fallback not working
ReportedBy TWiki:Main.PeterThoeny
Codebase

SVN Range Mon, 13 Mar 2006 build 9258
AppliesTo Engine
Component

Priority Normal
CurrentState Closed
WaitingFor

Checkins 9311 9312 9313 9389 9391 9520 9521
TargetRelease patch
Edit | Attach | Watch | Print version | History: r12 < r11 < r10 < r9 < r8 | Backlinks | Raw View |  Raw edit | More topic actions
Topic revision: r12 - 2006-04-01 - KennethLavrsen
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback