Tags:
create new tag
, view all tags

Organize TWiki Variables - for TWiki4.1?

This is a followup of EdinburghReleaseMeeting2006x06x26 - part of WhatIsIn04x01: How can we proceed to harvest what has been begun in TWikiRelease04x00x03 with splitting the TWikiVariables topic into one topic per variable? more... close

In short, I am seeing one bug but am unsure about the appropriate fix, and one extension which needs tedious, but straightforward work in a consistent way. This topic is intended to select the solution for the bug, and discuss whether my requirements are acceptable.

Issue: Links to "Related:" are broken in individual topics

Individual topics like VarWIKINAME are easily accessible and can be linked to - however, their (legacy) links to related variables only work in the compound TWikiVariables topic

  • Should they all link to the individual variables topics?
    • pro: Read only the variables you need
    • contra: If you've started with TWikiVariables (e.g. guided by some top-down navigation through the documentation) then jumping to individual variable docs is 1) slower than a simple anchor link and 2) creates duplicate information if you are using multiwindow or tabbed browsing
  • Should they all link to TWikiVariables?
    • pro: If you're following one link to a related variable, you might want to lookup more of them
    • contra: Every link to a related variable will link to the monster
  • Should they conditionally link to TWikiVariables when %BASETOPIC% was TWikivariables, and to the individual variable when %BASETOPIC% is an individual variable topic?
    • perhaps, only I couldn't make it work using %IF{}%.... and maybe performance will be too awful...
    • WIBNIF it could detect MiniAhah's Variable Explorer environment, too? wink

Proposal: I'd stick with linking to TWikiVariables, but only because it is easy to do....

Extension: Add topics for Preferences, Plugin vars, ...

In my opinion every %FOO{}% thingy which might appear in a topic, or everything which might be * Set, deserves a TWiki.VarFOO topic, to give the casual editor a chance to easily jump to its description

  • Examples: VarRED, VarX, VarCOMMENT, VarTABLE, VarGROUP, VarALLOWTOPICCHANGE...
  • This is a matter of diligence, not of difficulty.
  • Regions outside a %STARTINCLUDE% / %STOPINCLUDE% area can be used to link a variable documentation to its "parent":
    • Plugin variable docs MAY be pulled in with %INCLUDE% by the plugin topic
    • Plugin variable docs SHOULD link to the plugin topic outside their %STARTINCLUDE% / %STOPINCLUDE% area
    • Preference values SHOULD link to TWikiPreferences and the like outside their %STARTINCLUDE% / %STOPINCLUDE% area
    • Access control variables should point to TWikiAccessControl
  • A nifty 'edit' plugin/template could directly offer links to all variables which are used in the topic to be edited

Proposal: Open a bugs item to deliver at least the TWikiPreferences, access control, and distribution plugin stuff. </>

The first simplistic attempt to just create more variables for preferences (Bugs:Item2582) finally brought the discussion to life. To so much life that I have hidden the old content from your normal view.

Back to the drawing board

I'm separating requirements from implementation issues because I think it is really important that we accept the set of requirements before we start investigating the implementation options - at the risk that nothing will go into version 4.1.

What are the requirements?

Alphabetical List: We (KennethLavrsen in Bugs:Item2582 and HaraldJoerg) want a comprehensive, alphabetical listing of everything which can be found in topics as either * Set VARNAME = value, or as expansion of %VARNAME%. All combinations are found:
  • The content of TWikiVariables is not intended to be * Set but can be expanded. They may take parameters, some are quite complex. They are messages from TWiki to the users - or they should be seen only on the RHS (Right Hand Side) of equations, for grammar afficionados.
  • Preference variables (most of them documented in TWikiPreferences), access controls (TWikiAccessControl), and group member lists (* Set GROUP = ... in XxxGroup topics for TWiki's default user mapping) are usually * Set but never expanded. They don't take parameters (yet) and are messages from users/admins to TWiki. They should appear on the LHS (Left Hand Side, just in case) of equations. You can expand them, but there's little benefit doing so.
  • Rendering shortcuts are both set (mostly by TWiki admins, but everyone can do so in his home topic) and expanded. They don't take parameters (yet). They appear on both sides of the equations and are messages from users/admins to users, using TWiki as a store.
  • Erm... we're still missing variables which are intended to be neither * Set nor expanded. Any volunteers? hehe!

Categorization: We (PankajPant, PeterThoeny, MeredithLesly in CleanUpTWikiVariables, KennethLavrsen in Bugs:Item2582, CrawfordCurrie in his %MAPTOPIC% suggestion, and HaraldJoerg) want the variables categorized according to their origin (core, plugin, preference) and target group (beginner, power user, admin).

Unwieldy Topic: We (PankajPant, PeterThoeny, and HaraldJoerg in CleanUpTWikiVariables) are concerned about the unwieldiness of TWikiVariables if all the stuff is included.

Pluggable Documentation: We (CrawfordCurrie, SvenDowideit, and HaraldJoerg) want the mechanism to be fit for PluggableDocumentationArchitecture and component editing.

Implementation Issues/Suggestions/Open Points

Alphabetical List: A comprehensive list does not mean that each item in the list contains the documentation of all the variables inline. Just a list of variables, linking to their respective documentation, would do.

  • Suggestion: Create a new, lightweight topic TWikiVariablesIndex which contains really, really everything, and a yet to be defined number of collection topics, TWikiVariables and TWikiPreferences being two of them, and a bunch of separate topics for each variable.
    • If, in some future hierarchical-web-enabled release, TWiki variables inhabit a web of their own, this falls back to the WebIndex or WebTopicList.
    • As a consequence, the individual topics need to work indepently. Currently their "related" links are broken.
    • Individual topics for plugins should also show whether the plugin is enabled at the moment - which can be done with contexts in IfStatements.
    • Being able to use the GoBox to jump to any VarXXX topic is a bonus for the experienced user, but not technically required. Faster collections can be done if, for example, preferences have individual PrefXXXX topics.

Categorization: Could be done either as a form or as a bullet list in each of the individual topics. In HaraldJoerg's opinion, the technical requirement boils down to: "Can be captured by a %SEARCH{}% ". Could conflict with Pluggable documentation when documentation is in Perl code, or at least make discovery difficult if TWiki admins want to create own collections.

  • Suggestion: I've no opinion whether it should be a form or a bullet list. Forms make searches faster. They are rather rigid, too, which is both an advantage (because entries are homogeneous) and a disadvantage ("optional" fields look bad if empty, new fields aren't displayed in the appropriate position of of old topics).

Unwieldy Topic: Obvious problem. Current TWikiVariables + 100 preference variables (in SVN) + 200 plugins = nightmare.

  • Suggestion: See suggestion under Alphabetical List

Pluggable Documentation: There's disagreement about the implementation. The idea to put it in the source (SvenDowideit) is challenged by PeterThoeny and HaraldJoerg).

  • Suggestion: Think about an alternate generic format which could be used to generate both the grammar and documentation, or at least the grammar part of the documentation. Sort of CPAN:Getopt::Euclid for TWiki.
    • TWiki admins still need an easy way to document the rendering shortcuts they are defining. Example: Look at this topic's source and guess where the documentation of %FLIP% and %FLOP% would be.... In my installation, there is a TWiki.VarFLIP and TWiki.VarFLOP.

Bottom Line For 4.1

It seems that the requirements can not be fulfilled with creating just topics for all the preferences (as I've done so far). Plugins in SVN have an incredible amount of variable documentation, and for categorization we need to fix every single VarXXX topic we have.

So I am afraid that splitting TWikiVariables, however welcome it looked at that point (4.0.3), was just a "we can do that easily" and not a "we can use that". At least as far as I am concerned, I don't have a chance to do reasonable progress in direction of the requirements until September (there's holiday season for me as well, and I'm not going to twikiing...).

Keep the fire burning, and get it done in EdinburghRelease.

-- Contributors: HaraldJoerg and the whole horde of TWikizens mentioned above.

Discussion

There has been a previous attempt in this direction - CleanUpTWikiVariables. In my opinion the old topic should be flagged "Done" because the cleaning up of the monolithic topic has been released in 4.0.3, while we are discussing next steps here.

-- HaraldJoerg - 26 Jun 2006

I closed the old topic.

There is an opportunity here for a fundamental cleanup of the approach. Meredith has pointed the way with TWikiTags, which allow us to park the code for a variable in a separate place away from the rest of the core. So let's start thinking about variables as something we can plug into the rest of the system. I'd like to be able to do something like this at some point:

Have a special view mode, like raw=on. Maybe call it raw=variables. In this mode the topic is shown raw but each TWiki variable links to the relevant VarBARGLE topic.

Note that I am not advocating repackaging twiki variables using BuildContrib, just leveraging the tags work to improve their bundling, so creating opportunities for such improvements.

Now, it makes sense that we now have a definition of a twiki variable as a code module and a doc module. So %BARGLE% is implemented as:

data/TWiki/VarBARGLE.txt
lib/TWiki/Tags/BARGLE.pm

A further simple step is to add a link to TWikiVariables in the "Related" links at the bottom of each VarBARGLE page.

As for Preference variables. I'm not a big fan of shipping functionality in preference variables, for the simple reason that they are horrendously inefficient and I'd like to scale back their use. But if you do want to use them, I would favour collecting them together.

Here's one possible way to do it. In %USERSWEB%.TWikiPreferences, use

   * Set SWEET =  ...
   * Set SOUR = ...
   * Set UMAMI = ...
%MAPTOPIC{"%DOCWEB%.VarSWEET,%DOCWEB%.VarSOUR,%DOCWEB%.VarUMAMI" to="%DOCWEB%.VarTASTE"}%
Then, a WikiWord topic reference that finds %DOCWEB%.VarUMAMI, for example, could be automatically mapped to TWiki06x00.VarTASTE instead wherever it occurs. The "MAPTOPIC" variable could be a generally useful documentation tool.

-- CrawfordCurrie - 07 Jul 2006

It might be better to create a DocVariableForm that indicates what kind of variable it is (or where it came from): core, macro, plugin(+name), etc.

I noticed that TWikiVariables includes all variables using a search for topics named Var*. This would include all plugin specific variables too, which might not be the intention. Using a form would make it possible to include just the ones that are provided by the core.

Indicating an expertness level (beginner, intermediate, expert) would also make it easy to create VariablesForDummies, etc. that Meredith hinted at in CleanUpTWikiVariables.

-- PankajPant - 07 Jul 2006

All the suggestions so far - including that of PeterThoeny and the reply by KennethLavrsen in Bugs:Item2582 - suggest that the concept does deserve a closer look.

  • I absolutely agree with Crawford that a twiki variable should come with its own documentation topic:
    data/TWiki/VarBARGLE.txt
         lib/TWiki/Tags/BARGLE.pm
    This is very close to what I had intended to do with the distribution plugins. Example: data/TWiki/VarTABLE.txt should, in SVN terms, go into twikiplugins/TablePlugin/data/TWiki/ and not into data/TWiki. It can be a per-plugin-decision whether the plugin topic would %INCLUDE{}% its variable docs, duplicate it, or whether the plugin would have the VarXXX topic as just an one-liner pointing to the plugin topic. (I am, for what I think are obvious reasons, somewhat reluctant to start that work right now).
  • The idea of having a form for variable categorisation came into my mind as well. Such a change, which would make sense if almost all variables (and not just the preferences) would be categorised, would exceed the amount of time I am able to spend in the 4.1 timeframe, though it looks like the right way to go. All I did was a meek attempt to categorize with searches (data/TWiki/TWikiRenderingShortcut, data/TWiki/TWikiUserSetting).
  • It explicitly is my intention that TWikiVariables should include all plugin specific variables, because for some of them it is not too easy to guess the name of the plugin topic where their documentation is. Only if you have an easy way to map a variable name to the topic where it is defined allows any sort of "context help" when editing. Think of an input box in the edit template where I could enter a variable name, and get the corresponding documentation AJAXed in...
  • An expertness level is a very good idea to allow semi-automatic creation of document collections with searches.
  • I agree with PeterThoeny in Bugs:Item2582 (which I am too lazy to copy) that TWikiVariables is unwieldy when all the preferences are added. It will become much more unwieldy if a significant part of plugin variables are added: There are about 100 preference variables, but 200 plugins (though I doubt that any installation will have installed more than 50). And it might be a performance nightmare if some of the plugin variables come with examples.
  • I do not think that double documentation (in both TWikiPreferences and TWikiVariables) is a problem. Users will be intelligent enough to stop reading after they've found the first description.
  • Together with Kenneth I would defend a comprehensive alphabetical list of all variables.
    • One almost-power-user had the clever idea to define a rendering shortcut of
         * Set TABLE = <table cellspacing='0' cellpadding='0' border='1'>
      in Main.TWikiPreferences to speed up his typing. He claimed that he did a lookup in both TWikiVariables and TWikiPreferences to check for a name conflict. Can you imagine what happened to the topics which have been knowingly using the TablePlugin?
    • On the other hand, the comprehensive list is not required to %INCLUDE{}% the complete reference as well. A simple alphabetical list, similar to the first level expansion of the Variable Explorer in MiniAhah, should do as well.
  • For the preference variables, there's also the option to spin their documentation off into a TWikiPreferencesDocContrib instead of shoving all the topics into the core. However, this does not help to select "frequently used" preferences - it is an all-or-nothing.
  • Having done all the typing I agree with Crawford that TWiki has too many preference variables - a lot of them could go into configuration items or constant tags. Example: Who would think that customizing %BR% is a sensible idea?
    • If you really believe that I've typed all the topics in, then I'll sell you my old car. I've been using ttree from TemplateToolkit to do all the boring stuff (which, if you know TT, you might have guessed from the topics where I failed to get the line feeds right).

At the moment I tend to revert the change, go back to the drawing board, and maybe pack all the variables topics I've created so far into a zip file for the impatient. But the discussion is still open smile

-- HaraldJoerg - 07 Jul 2006

And again, I need to point out that for the advanced ComponentEdit work, I need a programatic definition of each plugin's grammar, and documentation for that grammar. So in I'd like to suggest that to give true plugable Tags, we should move the docco into the Tag.pm. The sooner we do that, the sooner we are able to show the user the documentation specific to their installed set of Tags..

  • Alas, we're not allowed to use the word Tag. I've painfully rewritten things to use Fn instead. The point still applies, of course. -- MeredithLesly - 10 Jul 2006
-- SvenDowideit - 08 Jul 2006

I am concerned that if we hide documentation in code it is hard to maintain, especially by non-programmers. How about a standard topic format that can easily be parsed? Such as enclosing the vital variable doc part a %STARTSECTION{"doc"}% and %ENDSECTION{"doc"}%? Or simply %STARTINCLUDE% and %STOPINCLUDE%.

  • You're missing the point. Sven is saying that Fns should be self-documenting. The documentation can then be pulled out and put into a topic for humans to read. It is far easier to maintain accurate documentation when it is stored with the code it is documenting. -- MeredithLesly - 10 Jul 2006
-- PeterThoeny - 10 Jul 2006

On categorization, we could add a bullet to every VarXXX topic:

-- PeterThoeny - 10 Jul 2006

Harald, if the intention is to have all variables listed in TWikiVariables, then at the very least it would be better to partition them by source, i.e. instead of one huge alphebetical list it could be something like:

  • core variables
  • defined in TWiki preferences
    • defined in web preferences (if that makes sense)
    • defined in user preferences (if that makes sense)
  • provided by plugin A
  • provided by plugin B
  • whatever makes sense

That would make it much easier/useful to read the page. This would only be possibly with some extra categorization, whether by a form or as Peter suggests.

-- PankajPant - 10 Jul 2006

We could learn by the WikiContextuality of ProWiki here (and on other places).

-- FranzJosefSilli - 10 Jul 2006

Back to the drawing board - time to refactor. smile

-- HaraldJoerg - 11 Jul 2006

A Background: Much of the debate is centering around the issue of "Drowning in information, but thirsty for knowledge". There is, in fact, an article with exact that title (by Paul Koeniger and Karl Janowitz). I read it years ago (previous century) when the web was very young, but unfortunately have lost my paper copy and any links. I recall that when I read it, I found it very impressive. It shows four categories for ordering information:

  • Hierarchy - just a list of links or the complete information? (the article has Micropedia/Macropedia from the British Encyclopedia as examples). The "customer focus" question is: How much does a reader actually read?
  • Sequence - sometimes "alphabetical" is appropriate, sometimes "most recent first".
    • Isn't it amazing how easy people find what they're looking for in a dictionary with 200000 words, just because they know the sequence? But have you ever thought about the sequence in a Japanese dictionary - with an alphabet of 2000 kanji signs?
  • Owner - information needs an owner, who is not necessarily the person who created it. The owner's name will have influence on the perception of quality of the information, but not only that: Given the impact of component editing and PluggableDocumentationArchitecture, we need to solve the problem of associating a piece of information with the plugin which "owns" it.
  • Time - the article emphasizes the different reader's experience between a newspaper and a book from just looking at it, before having read anything: Paper quality, page size, .... In internet terms things have been unclear when all we had were static websites, but the experience of different interfaces is coming back between IRC / Mail and News / Wiki / Static web site (many of them have been there for years, just not very popular). We are suffering from a mess between discussion and knowledge in Codev, but it is entirely unrelated to the current topic. However, documenting variables from plugins which do no longer work is related: If a plugin is disabled in a customer installation, or doesn't work after an upgrade, what happens to the documentation? Would the searches still collect the documentation topics?

-- HaraldJoerg - 11 Jul 2006

The time for version 4.1 is getting closer.

Harald checked in a lot of VarXXXX topics and they are still there. If we do nothing the TWikiVariables topic will defacto contain 164 predefined TWikiVariables and there will not be Plugin defined variables in it.

What Harald added was the variables that are defined by the TWikiPreferences and WebPreferences distributed per default.

To the normal user it makes no difference of %BR, %RED etc are defined in core code or in topics. We cannot ever capture any additional variables that an admin locally has added because it is not likely that he will have documented it in a standard way - even if we define a standard way.

There are many advanced proposals and a lot of Plugin related stuff.

For 4.1 I think we should limit the decision to

  • Do we accept the new VarXXXX topics or should these commits be reverted?
  • Do we revert only some of the topics?
  • Do we accept the Vars but organise them differently?

We need to make a decision within the scope of 4.1 at a release meeting because as I see there is not yet a concensus reached. But it will be better if the debate on this has some conclusions on which options we have. Personally I would vote for - review if some topics should be there - remove the few that should not - and leave it as it is for now for 4.1.

Originally 4.1 was scheduled to be released in September. This is not happening but October can happen. And then there is 4.2 where we can implement some of the nice advanced ideas above.

-- KennethLavrsen - 25 Sep 2006

Ken, you are right to raise this issue. Having all these variables is a two-sided sword. On the one hand, it demonstrates all the machinery available in TWiki. On the other hand it is daunting for new users and might scare them off.

Somehow there is also a conceptual difference between a tag such as %SEARCH% and %RED%. I cannot quite explain it, but they do feel different.

Anyway, 164 variables is a lot. It must be organized somehow to be less daunting...

-- ThomasWeigert - 26 Sep 2006

I think for TWiki 4.1 we should strive for a simple solution. My orginal idea was to document only the TWikiPreferences the users are like to use, not the ones for the administrators. Namely BR, BULLET, BB, BB2, BB3, BB4, YELLOW, ORANGE, RED, PINK, PURPLE, TEAL, NAVY, BLUE, AQUA, LIME, GREEN, OLIVE, MAROON, BROWN, BLACK, GRAY, SILVER, WHITE, ENDCOLOR, H, I, M, N, P, Q, S, T, U, X, Y. This helps in reducing the number of variables in the big list. I think variables such as NEWTOPICBGCOLOR, NEWTOPICFONTCOLOR, HTTP_EQUIV_ON_EDIT just confuse regular users, thus should not be shown in the TWikiVariables topic.

In TWiki 4.2 we can define a system where we can run reports that show variables for different use cases, such as variables for document authors, variables for pwer users, variables for wiki application developers, variables for TWiki administrators, etc. By default only variables for document authors should be shown. KISS (as in the TWikiMission).

Idea: Each VarXYZ entry could have a bullet used by the reports, such as:

  • Used by: DocumentAuthors, PowerUsers, ApplicationDevelopers, TWikiAdministrators
Or possibly without WikiWords:
  • Used by: Writers, Power-users, Developers, Administrators

-- PeterThoeny - 26 Sep 2006

I would not even do that list. They are already all documented elsehwere. E.g., the icon variables are documented on TWikiDocGraphics, the colors somewhere else, etc. Why can't we just point the reader to those pages for additional stuff and keep the variable topic as is, until there is time for more massive revamping?

-- ThomasWeigert - 26 Sep 2006

The original reason why Harald added all the topic was that both he and I had feedback from our users that they could not find which variables were available to them. And as Peter points out - it is the variables normal users use for writing topics that users have difficulty finding or never find out exists.

-- KennethLavrsen - 26 Sep 2006

I like the big list; having a definitive reference is IMHO essential. I don't want to have to pop between topics to find out about different variables. Please don't take the monster list away.

However I also understand the desire to winnow the list down to more manageable proportions. I don't like doing that by "class" - I for one never think of myself as a "Power user", "Document author", or any other such class. I would far rather have application-oriented groups. For example:

  • Searching and Listing - SEARCH, WEBLIST, TOPICLIST, ...
  • Controlling Formatting - BR, BULLET, RED, IF, ...
  • Access Controls - ALLOWTOPICCHANGE, DENYTOPICVIEW, NOSEARCHALL, ...
  • Getting Environment - USERINFO, GMTIME, SCRIPTNAME, ...
  • Controlling Environment - HTTP_EQUIV, NEWTOPICBGCOLOR, ...
  • Active content - links and forms - SCRIPTURL, QUERYSTRING, ...
etc.

Of course a single variable can easily be in multiple classes. It would be trivial to write a search page for these classes, though we would need some rules deciding what classes a variable goes into.

-- CrawfordCurrie - 26 Sep 2006

If we can implement Crawford's suggestion, that would be the best solution. Then we can have a top level bar with either look up alphabetically or look up by function. Sort of like the Perl documentation page.

We probably could quickly categorize variables. One variable can go into more than one group. Add a form field or tag that shows the category.

Let's start with Crawford's list of categories... Any additional ones?

-- ThomasWeigert - 26 Sep 2006

I've been silently watching this ( and other smile ) Codev page(s) and I also believe Crawford has got it right. Some other ideas include basically the sub headings of TWikiPreferences, no ?

  • Web Control - WEBTOPICLIST, WEBBGCOLOR, WEBCOPYRIGHT, ...
  • User Settings - EDITBOXWIDTH, EDITBOXHEIGHT, EDITBOXSTYLE, ...
  • Email Settings - ...

-- KeithHelfrich - 27 Sep 2006

The original question I got, and what made me start this discussion in November last year (CleanUpTWikiVariables), was more like "Why do I have to look in so many different places for the syntax of %TABLE%, %SEARCH%, %ALLOWTOPICVIEW%, and %RED%?" The author was new to TWiki and wanted to copy features from existing topics, and then change them to his needs. Not a bad strategy, usually, but badly supported by TWiki.

I would suggest to revert all the changes because

  1. we are pretty close to the intended release date which, at some time in the past, has been suggested for end of September
  2. if I am not mistaken, not one single plugin variable has been documented in a VarXXX topic
  3. I can't see a consensus about categories right now.
So what we have in SVN right now is another half-assed situation from which it is even more difficult to recover than from 4.0.3's "one topic per TWikiVariable" approach. For decent categories we need a toolset and conventions (forms/keywords) to hand out to creators of new variables, a layout for presentation. Such things need time to mature.

-- HaraldJoerg - 27 Sep 2006

I like Crawfords proposal from a developer perspective. However, having given a number of training sessions to new users I think beginners will be lost even with the variables sliced by type. Hence the need for a categorization by type of user. Think customer focus & KISS.

-- PeterThoeny - 30 Sep 2006

Categorization by type of users may not help because Users don't know which "type of users" they are. Borrowing the term from http://headrush.typepad.com/creating_passionate_users/(everybody go read her http://headrush.typepad.com/creating_passionate_users/ about creating passionate users now), average users want to know "How do I kick ass with this app?", and power users want to know "now that I kick ass, what else can I do?".

Note: Here I use the term "users" as in "person that creates content in TWiki". Thus TWiki Admins, and every other kind of persona that don't create content is excluded from these consideations.

Average users want to answer thinks like "what was that variable to include other topic?", while Power Users will want to answer "What is the parameter for the INCLUDE variable to include only a section of a topic?".

So, this is what I imagine the reaction of these kind of users

Kind of listing Average User Power User TWiki Hacker
Complete Listing "WTF!?" "Here is the INCLUDE variable!" "/bin/view/TWiki/varINCLUDE"
Categorized "Hmm, Topic Manipulation... Here, INCLUDE variable is what I need" "Topic Manipulation... INCLUDE .. good" "/bin/view/TWiki/varINCLUDE"
By type of Users "Hmm, I'm a Beginner user, I guess... no, there is no variable to perform include another topic" some may stop here, some will say " perhaps I'm a Knoledgeable User... yes, there it is, INCLUDE" "I kick ass, so I'm a Power User... Wait, where is the INCLUDE tag!?. Let me see in Beginer, it's pretty simple stuff... nope?! so, it's a Knowledgeable var.. crappy system... here it is, INCLUDE, let me bookmarkit so I will not lose it again" "/bin/view/TWiki/varINCLUDE"

It's very difficult to clasify users in a way that fit all the possible schemas in every organization. Furthermore, "normal" users will be scared away from some of the most amazing features of TWiki if they are labeled "advanced" or "power users" or "developer stuff".

IMO, for them benefit of the users (those that generate content), it's better to classify the variables by "Use Case" rather than "by type of users". And it's even better if the complete listing remains for the benefit of the users that needs a Quick Reference.

-- RafaelAlvarez - 30 Sep 2006

Raffael, well said. To add, the beginner user is best served with the table in TextFormattingRules. Once you look at variables, you are not a beginner any longer, and there is a wide continuum of users...

-- ThomasWeigert - 30 Sep 2006

DECISION from EdinburghReleaseMeeting2006x10x02

PeterThoeny removes the VarXXXX topics that are admin types as the action for release 4.1. (This does not exclude further improvements for later releases).

This means that the the added VarXXXXX topics in general will remain as already checked in except a subset that are admin types which the admin will only adjust on the TWiki. or TWikiPreferences anyway. The ones that will stay are the ones users will use when writing topics and Twiki apps. Release meeting agreed to leave it to Peter to decide which ones to remove.

-- KennethLavrsen - 05 Oct 2006

I removed some variables that have been added in Bugs:Item2582, as agreed on in EdinburghReleaseMeeting2006x10x16:

VarATTACHEDIMAGEFORMAT, VarATTACHFILESIZELIMIT, VarATTACHLINKBOX, VarBROADCASTMESSAGE, VarCOMPOSER, VarDONTNOTIFYCHECKBOX, VarEDITBOXHEIGHT, VarEDITBOXSTYLE, VarEDITBOX, VarEDITBOXWIDTH, VarFAVICON, VarFINALPREFERENCES, VarFORCENEWREVISIONCHECKBOX, VarHTTP_EQUIV_ON_EDIT, VarHTTP_EQUIV_ON_PREVIEW, VarHTTP_EQUIV_ON_VIEW, VarHTTP_EQUIV, VarINCLUDEWARNING, VarLINKTOOLTIPINFO, VarMAILTHISTOPICTEXT, VarMAILTHISTOPIC, VarNEWTOPICBGCOLOR, VarNEWTOPICFONTCOLOR, VarNEWTOPIC, VarNOAUTOLINK, VarNOSEARCHALL, VarPREVIEWBGIMAGE, VarSEARCHDEFAULTTTYPE, VarSEARCHSTOPWORDS, VarSEARCHVARDEFAULTTYPE, VarSITEMAPLIST, VarSITEMAP, VarSITEMAPUSETO, VarSITEMAPWHAT, VarSKIN, VarTWIKILAYOUTURL, VarUSERCOLORSURL, VarUSERLAYOUTURL, VarUSERSTYLEURL, VarWEBBGCOLOR, VarWEBCOPYRIGHT, VarWEBFORMS, VarWEBHEADERART, VarWEBHEADERBGCOLOR, VarWEBHEADER, VarWEBLOGOALT, VarWEBLOGOIMG, VarWEBLOGO, VarWEBLOGOURL, VarWEBRSSCOPYRIGHT, VarWEBTOPICLIST, VarWIKILOGOALT, VarWIKILOGOIMG, VarWIKILOGO, VarWIKILOGOURL, VarWIKIWEBLIST, VarWIKIWEBMASTERNAME, VarWIKIWEBMASTER, VarALLOWTOPICCHANGE, VarALLOWTOPIC, VarALLOWTOPICVIEW, VarALLOWWEBCHANGE, VarALLOWWEB, VarALLOWWEBVIEW, VarDENYTOPICCHANGE, VarDENYTOPIC, VarDENYTOPICVIEW, VarDENYWEBCHANGE, VarDENYWEB, VarDENYWEBVIEW, VarTWIKICOLORSURL, VarTWIKISTYLEURL

These are all preferenes variables not typically used by content creators as %VARIABLES%. This is to avoid confusion; for example, "should I use %NOAUTOLINK% or <noautolink>

This is Bugs:Item3006 and SVN 11725/ 11729.

-- PeterThoeny - 16 Oct 2006

I added two missing rendering shortcut variables: VarENDCOLOR and VarVABR.

-- PeterThoeny - 16 Oct 2006

Hm, never read about a TWikiVariable called VABR. What does it do?

-- FranzJosefSilli - 16 Oct 2006

Typo, that's VarVBAR as in vertical bar or pipe symbol. Typically used in TWiki tables.

-- PeterThoeny - 16 Oct 2006

Oh, I see. | smile

-- FranzJosefSilli - 16 Oct 2006

Edit | Attach | Watch | Print version | History: r31 < r30 < r29 < r28 < r27 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r31 - 2010-07-07 - PeterThoeny
 
  • 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-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.