archive_me1Add my vote for this tag create new tag
, view all tags
Thanks to AttachLinkNotStruckOutInPatternSkin I have been forced into thinking about a couple of related problems:
  1. How do plugins authors know what context their code is being called from?
    • commonTagsHandler is called from many places in the code, and having some way to let the plugin author know what context it is called in is important.
  2. How do template authors know what context their code is being used in?
    • How do you disable links when showing old revs, for example?

For simplicity, let's consider plugins first. Now, a plugin author can tell (with a bit of luck) where they are called from using a variety of very unreliable mechanisms - for example, they can count calls, or they can parse the URL, or they can examine some other bit of context that is normally set up. But it's very haphazard; we need a generic mechanism for telling plugins where the calls are coming from. I propose that the session object should maintain a stack of context identifiers that can be pushed and popped and queried by plugins.

sub contextIncludes( $id ) -> boolean

Tests if the current context includes the context identifier $id. Legal context identifiers are as follows:
  • view - this is a view operation
  • edit - this is an edit operation
  • preview - invoked from a preview script ...
Any new scripts added by skin or addon authors can set the context appropriately.

The second related problem is how to tell the context in a template, and how to change behaviour based on that context. At the moment, the only way is to rely on the code processing the templates - for example, %!EDITTOPIC%. But this is very fragile, as evidenced by AttachLinkNotStruckOutInPatternSkin, and is not portable between skins.

A reasonably clean solution would be to extend the TMPL:P statement, and use it to detect the context. For example

I like %TMPL:P{ifcontextincludes="breakfast" then="bacon" else="eggs"}% for %CONTEXT%
This yields, for example, "I like bacon for breakfast" or "I like pasta for lunch". Ifs can obviously be nested inside TMPL:DEFs.

This leaves the option of adding a generic "if" attribute to TMPL:P in the future, it adds the minimum of new syntax, and can be used from topics as well as from templates (though you can only use TMPL:DEF in templates, of course).

Thus the solution for the "Edit" link strikout is as follows:

%TMPL:DEF{"edit_active"}% <a href="%EDITURL%/%WEB%/%TOPIC%">Edit</a>%TMPL:END%
%TMPL:DEF{"edit_disabled"}% <strike>Edit</strike>%TMPL:END$

%TMPL:P{ifcontextincludes="oldrev" then="edit_disabled" else="edit_active"}%

I propose adding this for Dakar.

-- CrawfordCurrie - 22 May 2005

OK, much to my suprise this was quite easy, and we now have the "context if" support described above. And it's documented. I deprecated EDITTOPIC by adding a variable to TWikiPreferences, which should work for anyone with their own skin. SVN 4303

-- CrawfordCurrie - 22 May 2005

Crawford, this is excellent, albeit one may quibble with your choice of syntax, which is probably more verbose than needed. I am also concerned that the syntax requires the branches to be inside of strings, which is not consistent with the other templates. If would have preferred something along the lines of

with no limitations on the text that can occur inside the braces. If you need keywords for parsing, use %THEN{<then>}% etc.

Secondly, please document the list of currently supported context words... in your doco above you do not mention oldrev but it appears to be used for the strikeout of links.

-- ThomasWeigert - 23 May 2005

The syntax was chosen because it works within the scope of the existing syntax. The 'then' and 'else' clauses are template names and not blocks of code. Yes, it's more verbose than needed, but it avoids any need to parse the templates when they are read. Using this syntax the entire implementation is 9 lines of code!

It's already documented, in TWikiTemplates. I added the minimum set of context identifiers I was certain are needed. There are probably other identifiers that need to be added, but I thought I should keep the set small in case I added useless IDs and we ended up locked into supporting them.

One potential problem is the way TMPL:P is handled. TMPL:P's used inside templates are fully expanded during template reading, so the context ids have to be in place before the template is read, which is very limiting. I need to do some experiments to establish if template expansion can be delayed until instantiation.

-- CrawfordCurrie - 23 May 2005

I did the experiment, and was able to limit early expansion to simple tags ("old style" TMPL:P's) only, and leave the context-sensitive versions to expand only when the template is actually used.

-- CrawfordCurrie - 23 May 2005

Edit | Attach | Watch | Print version | History: r7 < r6 < r5 < r4 < r3 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r7 - 2008-09-15 - TWikiJanitor
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.