• 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.
Renamed from AutoAttachment does not respect VIEW_TEMPLATE

Original problem description: Let's say you use the following VIEW_TEMPLATE for your TWikiApplication:

%TMPL:INCLUDE{"view"}%

%TMPL:DEF{"content"}% 
<!-- hidden text

--> %TMPL:END%

Then attachments are still displayed at the bottom of your page even though there's no META{"attachments"} attachments in sight.


ALERT! Start here

The rewritten ViewDotPm requires that the string %TEXT% is in the view template, otherwise everything goes wrong. This cannot be presupposed, as a template designer may decide not to have a text area in the topic due to the needs of a particular application.

The problem code in question is:

    $tmpl =~ m/^(.*)%TEXT%(.*$)/s;

    my $start = $1;
    my $end = $2;
We must find some different way of handling this, or at least, be resilient when %TEXT% is not there... --TW


Hum. The split on text was intended to clean up and simplify tag expansion.

The right way to do this is to separate the view template into head, body and footer %TMPL:DEFs, and then instantiate them in View.pm.

CC


I assume you mean similar to how it is done in, say, the search templates. That is a good suggestion. Just one question... the only thing we do with the start and end sections is to set context when they get "prepared". Is that really worth all the hassle? --TW


Followed up on Crawford's suggestion. Use %SPLIT% marker to separet the view template into three sections, the middle of which usually contains %TEXT%, but need not.

Using this convention, Michael's example has to be written as follows

%TMPL:INCLUDE{"view"}%

%TMPL:DEF{"content"}% 
%SPLIT%%SPLIT%
<!-- hidden text
   * Set USERSTYLEURL = http://ntwiki.ethermage.net/~develop/pub/Bugs/HideTextarea/hidetextarea.css
--> %TMPL:END%

Note that the USERSTYLEURL variable is not needed, i.e., the example also works as below. Hiding the text area that does not exist serves no purpose...

%TMPL:INCLUDE{"view"}%

%TMPL:DEF{"content"}% 
%SPLIT%%SPLIT%
%TMPL:END%

Personally, I would recommend against using css to hide the text area, as it ist still there and you may end up with unexpected results. I would remove the text area from the view mode altogether, as in the example.

Fixed in SVN 6534. --TW


This solution breaks, for example, ?skin=text. And all other skins (that doesn't have =%SPLIT%='s.

Wouldn't it be easier just:

    $tmpl =~ m/^(.*)%TEXT%(.*$)/s;

    my $start = $1;
    my $end = $2;

    $start = $tmpl unless ($start || $end);

If there is no %TEXT%, then there is only a start (or an end, doesn't matter). AT


Actually, this revealed an erroneous (?) file in the templates dir: view.text.tmpl, which had only %TEXT% as content. Now, I might be mistaken, but this file must be a mistake. I deleted this file, and now ?skin=text works as expected (at least on my machine, ethermage has not updated yet). Fix in SVN 6538.

You are right in that every skin needs to update the view template.

CC, any opinions on your original strategy or what AT suggests? --TW

On reflection, I think view.text.tmpl must be a hangover from a hack. I tried ?raw=text, ?skin=text, ?raw=on;skin=text, and they all behave as I would wish them to.

The horrors of the template architecture is what put me off dabbling with this before.

The SPLIT solution you added is valid, but breaks compatibility with existing skins, and has a high risk of confusion with other SPLIT tags that appear at seemingly random points in the templates. So I'm reverting it and going with something closer to Antonio's solution.

  • As an aside, there is no risk of mixing up the %SPLIT% tags in the templates, as they are in different templates that are not intermixed (today). --TW

SVN 6545

CC


CC, your update reintroduced the original problem. I have modified your update so that it also addresses the issue of omitting %TEXT% in a template. SVN 6549

There is an interesting side effect: if we use, e.g., ?raw=text, there is no text shown at all. Here are two alternatives, and I am not sure what the requirements actually are:

  • Because the template does not include any text and thus there will be no text rendered in the view mode, the raw mode should not show any text either
  • Because the raw mode shows what is in the topic file without rendering, it should show the text that is in the topic, even if the view mode will not show it.

Please advise as to what the requirements for this feature are. --TW


I've added view.text.tmpl back, as it's used in at least two applications (that I wrote myself ;)) and has one use: to get content from a topic without surrounding "<html>...<body>" and "</body></html>" and with markup expanded.

r6552 AT


No, I am sorry, but you cannot use this file. It is completely inconsistent with the templating scheme. view.text.tmpl would have to be a template for a text skin. Please remove this file as it messes up text skin (would such a skin exist), and we don't ship such a skin.

We either would have to add a text skin or stay away from that name. When you add templates you have to be consistent with the templating scheme, please. -- TW


However, Antonio is right. Cairo shipped the 'text' skin, for view at least, and to remove it now breaks compatibility. Antonio didn't add the template, he re-used a template that was already there. And it is a template for the text skin, I'm afraid. So it needs to stay.

CC


AT, sorry, I did not realize that we had a skin consisting only of one topic. Still don't understand its purpose.... -- TW
Thomas, thanks for clearing up my mistake, you were right.

The requirement for ?raw=text was to generate an output suitable for wget to subsequently pipe to a file, and thereby reproduce the source of the topic on the client machine. Therefore only a Content-type: text/plain header, and the raw text of the topic, is supposed to be served. The template is to be ignored. (This is why I made the param ?raw=text, in place of the old ?raw=on;skin=text - I felt that the latter was an abuse of the templating system, and confusing as well.) --CC


CC, so sorry, but I still don't understand. What does it mean to recreate the raw text of the topic in ?raw=text ? Try this on a bug topic, and you get a single line: the hidden Set that points to the css hiding the topicarea. Clearly that is not a meaningful recreation of any bug topic?

What about the form where all the action is? This text, in fact, is just a directive for the renderer... --TW


i've used the skin=text before as well (for TWiki:Plugins.TWikiInstallerContrib); it needs to stay. the reason you're not seeing anything useful for bug topics is because this is a form-driven TWikiApplication.

Compare:
http://twiki.org/cgi-bin/view/Codev/WebChangesForAllWebs?skin=text;raw=on
vs.
http://twiki.org/cgi-bin/view/Codev/WebChangesForAllWebs?skin=text;raw=debug

you need raw=debug to get to the form data. yes, you could argue that these are poorly-chosen parameter values, and i would agree with you; unfortunately, they've been around forever.

also note these views tend to be driven by scripts and wget, rather than being viewed in the browser. it's a way to get the plain, raw topic (and form data) text. WN


I am not comfortable with having such a partial solution, in particular if there is no documentation nor established requirements. Questions such as the following should be answered: "Why should the text skin show text for a topic if the standard view mode does not show any text?"

I think this is an abuse of the skin mechanism. Of course, everybody is free to implement that on their own system, but I don't think it is appropriate to ship this with the system. A skin should apply to all modes, not just to a single one.

It makes much more sense to me to include a further special case under the debug modes which would just print out the raw topic text without any adornment, similar to ?raw=debug or ?raw=on or ?raw=text.

A skin should be applicable to any mode, such as edit, preview, search, etc. I should be able to set a skin in * Set SKIN = text for example, but that makes no sense for this supposed text skin. -- TW


I thought I had documented ?raw=text in TWikiScripts. Maybe not sufficiently. The answer to your first question above is "It shouldn't, and it doesn't". There is no special treatment of of the text skin in the View script. It's just another skin.

The "special modes" use raw - raw=on, raw=debug, and raw=text. The first two show text in a textarea. The third shows the raw text of the topic. If it's missing the form data, then that's a bug.

As for established requirements; no, of course not. TWiki was hacked, as far as Cairo. I have derived requirements where I could, but maintaining compatibility in this area has been a nightmare. CC


Crawford, this discussion is not about the ?raw=text special mode, but about the pseudo skin ?skin=text.

The problem with the pseudo skin "text" is that if you set this to be your skin, in all modes other than view it will show the classic skin. In view mode it shows the text formatted without any header or footer area, whether the text is visible in view or not.

This is not how a skin should behave. -- TW


To your point about special modes, ?raw=text does not behave as you describe. It shows only the text, unformatted, but not the form data, see http://develop.twiki.org/~develop/cgi-bin/view/Bugs/Item450?raw=text. -- TW
Updated the doco in TWikiScripts to make it a little easier to understand. SVN 6576

However, I think that the ?raw=text special mode is rather inconsistent. The other raw modes show the source in a text area, but the rest of the topic is formatted as usual (WebLeftBar, task bar, topic actions, header and footer are shown). However, ?raw=text only shows the raw text, no other formatting.

And then we have the ?skin=text mode which shows the text of the topic only, but formatted.

To repeat, I think the ?skin=text is an abuse of the skin mechanism. In addition, I still don't quite see the motivation above.

I think this mode should be eliminated. It might have been in Cairo code, but certainly it was nowhere documented. We have no responsibility to preserve undocumented features, in particular, if they are as easy to restore in one's own installation as this one: just add a template file. -- TW


Historical note: This is all my fault, view.text.tmpl was supposed to allow TWiki:Codev.UsingTopicToDefineCSS (the original patch is in the topic text) but there were problems that meant it wasn't used for that in the end. That's probably why it doesn't contain the form metadata. --SH
ALERT! If I here no further convincing arguments regarding the ?skin=text mode, I will delete this file from the distribution. --TW
Responding to:
"A skin should be applicable to any mode, such as edit, preview, search, etc. I should be able to set a skin in * Set SKIN = text for example, but that makes no sense for this supposed text skin. -- TW"

"The problem with the pseudo skin "text" is that if you set this to be your skin, in all modes other than view it will show the classic skin. In view mode it shows the text formatted without any header or footer area, whether the text is visible in view or not.

This is not how a skin should behave. -- TW"

Shouldn't view.rss.tmpl be deleted for the same reasons? That's what I based my original patch on. It's not a proper skin either, nor are the plain or print templates.

The point I'm trying to make is that this use of templates isn't without precedent -- SH


Sam, you have a good point. Apparently there have been two uses of the skin mechanism:
  • Define a systematic change in appearance of a TWiki installation
  • Modify the appearance or content of the view mode
The latter can also be accomplished using the VIEW_TEMPLATE mechanism; we could pass it in as a URL parameter just like skin.

I think that if something does not make sense to be set as a SKIN globally, it is not a skin and should not be used such. --TW


Another case; WysiwygPlugin uses edit/.../...?skin=kupu. The editor on startup uses view/.../...?skin=kupu to get the topic source after processing through a specialised rendering pipeline. The skin mechanism is a flexible way to let me do that, just as ?skin=text is a simple way to get rendered bu unencumbered text.

Another way to achieve the same thing might be to use covers. Covers are skins that only apply for the duration of a single request, and stack over any other global skin specification. So ?cover=text should work, as should ?cover=kupu. I avoided using this, as it isn't compatible with previous releases.

Can we close this topic now? Please? (Deferred to Edinburgh)

CC

Undeferred, post Dakar CC


The actual proposal here is that TWiki/UI/View.pm script (and therefore the view template) should be re-engineered to assume three sections; before text, text, and after text, using TMPL:DEFs. That would allow us to handle templates with missing %TEXT robustly.

Dropping to Normal priority.

CC

Fixed but not marked as such long time ago.

MD

ItemTemplate
Summary View requires %TEXT% to be in template
ReportedBy MichaelDaum
Codebase

SVN Range

AppliesTo Engine
Component

Priority Normal
CurrentState Closed
WaitingFor

Checkins 6534 6538 6545 6549 6552 6576
TargetRelease major
ReleasedIn

Edit | Attach | Watch | Print version | History: r31 < r30 < r29 < r28 < r27 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r31 - 2007-07-09 - TWikiUserMapping_MichaelDaum
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback