Feature Proposal: Add a way to display the contexts that are set

Motivation

I would like to add a set of css classes that are dependant on the contexts that we are in - that way I can customise the css for each of the script operations, permissions, etc.

Description and Documentation

Description of what this feature should do

• needs to use the format, and separator specifiers

Examples

<div class="%CONTEXT{sep=" "}%">
stuff
</div>

<div class="view authenticated body_text SpreadSheetPluginEnabled SomethingPluginEnabled ... MyPluginSetThisContext">
stuff
</div>

thus freeing me up to add css that does conditional things based on any of the above container classes (I was intending on adding that list to my html body)

Impact

Implementation

-- Contributors: SvenDowideit - 14 Mar 2008

Discussion

"Context" in this case I assume refers to the internal context identifier (which is available for checking from %IF, but cannot be directly tested. Currently the only way to "recover" the context such that it can be used in rendering is using an %IF statement; for example: < p class="%IF{"context view" then="view" else="notView"}%Paragraph>

However from other conversations, I suspect what you are really asking for is access to the name of the current script context - view, edit, attach etc. Simply providing access to the context hash wouldn't give you this, because there is no script context variable that gives you the name of the script context.

-- CrawfordCurrie - 15 Mar 2008

What I am after is the list of current contexts that are 'testable' via IF. but I don't think that writing a series of IF's to output each of the possible contexts is worth it, compared to just giving us a way to output them directly.

I don't just want the name of the current script - which is available from the context list, but also if we're running from the command line, and the names of contexts that I've set from my plugins, and even the names of all the enabled plugins, and any other extra features.

I do, specifically, want what I asked for.

The hard part, is working out howto evaluate the TML late enough to catch as many contexts as possible, howto deal with contexts that are WikiWords, and other little pains.

-- SvenDowideit - 15 Mar 2008

I find this feature request high up on the nerdometer. Possibly ImplementedAsExtension?

-- PeterThoeny - 16 Mar 2008

Having a %CONTEXT{}% tag is a good idea. Remember we could refactor some of the skins as well as there is a context checker in TMPL as well...which would be superseeded easily. Actually %CONTEXT{}% should have been there right from the beginning when the context hash was added to the twiki core and been used for all sorts of things and which are really useful to know about in TWikiApplications.

-- MichaelDaum - 16 Mar 2008

I'm not sure about the nerdometer - this is basically a symetry of TML language issue - if you can test for it, you should be able to display it.

That said, I'm starting to think more about beging a Plugins to let us experiment with these concepts.

-- SvenDowideit - 18 Mar 2008

Ah, it is only a few lines of code and a natural thing to export from TWiki's internals out to TML-land. A plugin would have to violate encapsulation anyway.

-- MichaelDaum - 18 Mar 2008

A plugin would not need to violate encapsulation; the contexts are already available to plugins (via TWiki::Func::getContext). I share the view that this is high on the nerdometer, but as Sven says, it is a symmetry issue. It doesn't have to be "in your face", but it should be available for display.

-- CrawfordCurrie - 19 Mar 2008

I am changing this to ParkedProposal until we find an owner.

-- PeterThoeny - 2009-11-24