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

Motivation

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

Description and Documentation

amend QUERY to output context - and other unary operators - to simplify user debugging, (ie, they can display any 'thing' they can test, and to allow us to use them as appropriate.

Examples

<div class="=%!FOREACH{"%!QUERY{context}%" separator=" "}%=">
stuff
</div>

would render to

<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

WhatDoesItAffect:

Rendering %WHATDOESITAFFECT%

edit

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 beginning a Plugin 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

this proposal is superseded by the CleanerSyntaxForMetaDataAccess proposal.

%EVAL{context}% or more specifically %!FOREACH{"%!EVAL{context}%" separator=" "}%

I would however like to propose that this be placed into the core skins' body css class.

-- SvenDowideit - 25 Feb 2010

You cannot set a date for commitment in the past. I have reset it as today.

Otherwise our 14-day system does not work.

What is it you actually propose now? The original proposal or something new?

-- KennethLavrsen - 25 Feb 2010

Hmm, I don't recall context being supported by %IF/%EVAL/%GET as a nonary operator; ATM it's a unary operator returning a boolean. That's not to say it can't be done - it can - just that there's no code there yet.

-- CrawfordCurrie - 25 Feb 2010

sounds like your new QUERY will need to do more than it does atm as I pointed out on irc, a user trying to work out an IF / SEARCH will expect to be able to display the values they are trying to test for..

Kenneth - assuming that QUERY actually gets implemented in the way a user would expect, then this proposal is 99% redundant - the only thing we will need to do is to add the QUERY macro to the class= param of the default template's html body.

-- SvenDowideit - 06 Mar 2010

I'm struggling with the value of this. You've given one example where the context names are being mapped to CSS class names - definitely not their original purpose. What other uses are there for this?

-- CrawfordCurrie - 09 Mar 2010

Sven. The QUERY proposal has been passed.

And you say this proposal is redundant if this was passed.

Does this mean you can pull back this proposal?

If yes. Set it to Rejected with reason NoCommittedDeveloper.

-- KennethLavrsen - 09 Mar 2010

I have to either send this for community vote, defer it for 2.0, or go with my interpretation of Sven's statement that the QUERY proposal makes this proposal redundant.

I am going with the interpretation. Sven. If you finally get the time to react on this, revert my decision and ask for community vote if you still want to see this passed.

-- KennethLavrsen - 24 Mar 2010

no, its not redundant, as QUERY does not implement the unary operators - such as 'context', making it harder for users to debug the IF tests they write.

I've deferred this to 2.0, at which point we can look further.

-- SvenDowideit - 02 Apr 2010

Thanks for clarifying.

I put the date back to original. It was a bit confusing with a date in the future.

I will organise community vote sometime in May after we branch off Release01x01

Unless Crawford pulls his concern

-- KennethLavrsen - 02 Apr 2010

I'm not going to do that; I'm still dubious of the value of this. I suspect it's so old it's irrelevant. Sven?

-- CrawfordCurrie - 07 Dec 2010

No response from Sven in the last 2 years, so I'm rejecting this. I really don't think it's appropriate for core functionality. If FOREACH were core, perhaps, but it isn't.

-- CrawfordCurrie - 17 Feb 2012

Commenting is disabled while not logged in