Tags:
archive_me1Add my vote for this tag create new tag
, view all tags
See also: ConditionalPlugin (adds conditional rendering), SpreadSheetPlugin ($IF formula), SmartSessionPlugin (conditional text depending on login)

NOTE: Conditional rendering like for example: %IF{ %TOPIC% eq WebHome }% This is WebHome %ELSE% This is NOT WebHome %ENDIF% is now possible if you install JeroenVanDongen's ConditionalPlugin.

-- PeterThoeny - 11 Aug 2002

I think I'm violating the basic KISS principle here, but the %STARTINCLUDE% and %STOPINCLUDE% variables gave me the idea, so here it goes...

In some cases you might want to put text in a general page that will be included from many places, but you might want to customize it a bit depending on where it is included.

In some other cases you might want a generic help page that changes slightly depending on the web that it's being called from.

For example, it would be nice to offer help for all plugins in the main TextFormattingRules page, but only show the help for the plugins that are actually installed in the particular web, if it is invoked from an Edit template (this would require a parameter to be passed when the topic is used).

So, why not a "simple" conditional rendering directive, like:

%IF{%GMTTIME% ~= "Jan 1"}%
__Happy new year!!!__
%ENDIF%

%IF{% BASETOPIC% != "Main.WebHome"}%
Main.WebHome will take you back to the main page.
%ENDIF%

To keep life simple, probably no inclusions, or nesting, should be allowed inside such construct.

-- EdgarBrown - 10 May 2001

You bring up a good point. The TWiki syntax could be extended to include program like constructs. This is what ColdFusion, JSP and ASP is all about, mixing HTML with program code. It is a simple and powerful way to create web apps. One downside is that you mix presentation and code, which does not scale well if want to create a big app where UI experts and programmers are not the same people. For an editable TWiki site it means also that security must be designed into it.

-- PeterThoeny - 17 May 2001

This does sound like a nice feature, but a shame to re-invent the wheel when PHP et al have already done this quite a lot. One interesting approach is shown in http://www.c2.com/cgi/wiki?WebMacroWiki and http://wiki.webmacro.org/WebMacroWiki - this is based on WebMacro, which is a Java-based framework for building web applications that clearly separate layout/design, programming, and content. Probably too heavyweight for TWiki but might have some good ideas.

-- RichardDonkin - 17 May 2001

I've been thinking about refactoring some of the 'help and introduction' type pages in my company's TWiki setup and have realised that this sort of conditional would be very useful - for example, one web, call it Foo, has a local convention that all changes in thread-mode pages should go at the top, which is useful to include within the Main web's help page but only make visible when viewed within the Foo web.

In terms of implementation, why not allow pages to be post-processed through an existing tool such as PHP or ASP? We already allow HTML as an extension of the TWiki syntax, so embedding such a language would work in a similar way. Of course, there are security issues with letting most people use scripting, particularly if a third party tool such as PHP is used, so this should be controlled to start with by TWiki's access control features (only allow some people to edit pages with PHP).

It is possible to just fork PHP as an interpreter (for ease of initial implementation), and its syntax is based on angle brackets, so it would not conflict with TWiki's. In the longer term, it might be possible to embed the CGI calls to TWiki within PHP pages, for better performance - see http://www.phpbuilder.com/forum/read.php3?num=2&id=110794&thread=110788 and http://www.php.net/manual/en/function.virtual.php (doesn't allow CGI output to be interpreted, though). Maybe TWiki could write to a .php file, then redirect the main HTML page on the server side to that PHP page.

PHP runs on Windows as well as Unix, and supports most web servers - it's the most popular add-on module for Apache, according to http://www.php.net/usage.php. There's more info at http://www.php.net/.

If there's sufficient demand, perhaps a simplified language could be included within TWiki for conditionals, but I think that initially just re-using PHP would be a good approach, which would also add a lot of power to TWiki.

-- RichardDonkin - 20 May 2001

If you want an embedded language, just use Pearl since that's what TWiki is written in.

I suggest a construct something like:

%PEARL( perl script goes here )%

Of course, it leaves a security hole a mile wide and thus should be disable-able on public webs, or it might be a capability of certian people/groups.

-- DavidLeBlanc - 21 May 2001

I'm considered a seperate idea based on SubTopics which allows a Rendering on a particular topic (subtopic) handle dependant on some meta-information contained within that subtopic. You would need also some way of allowing subtopic information to be display in the parent topic.

If you allowed for plugins to be managed from a web interface this would provide also the same benefits with probably less risk.

-- NicholasLee - 21 May 2001

PeterThoeny mentions that the TWiki formatting syntax could be modified to include more constructs, but brings up the importance of security. RichardDonkin mentions using PHP, but I think that's a big bit of overkill and a nightmare with respect to security, not to mention it scares me as a PHP/Perl frankenstenian nightmare. DavidLeBlanc suggests just including raw perl, which although not quite frankensteinian, still would be security scary.

But, has anyone looked at TemplateToolkit? I haven't yet really dug into things, but I notice that the current templating is a kind of ad hoc accumulation of regexes. (No offense to anyone) The current TWiki regex filters could be transliterated into a TWiki "filter" plugin for TemplateToolkit that is wrapped around blocks of TWiki content.

One of the nice things about TemplateToolkit, is that it has a fairly simple yet complete programming construct set, and a plugin architecture to add further capabilities. If you want, you can turn on raw perl code inclusion, or leave it off to lock down page coders' access to the system. And if you want, you could restrict the TemplateToolkit processing to templates, and not user-entered content.

Anyway, just an idea I was thinking of playing with myself as I started poking around with TWiki...

-- LesOrchard - 01 Jun 2001

Given that this topic has gone way over-board, I was re-thinking this, and the basic functionality that I would like to have is the capability to decide which part of a topic gets included in another one.

I might have (as I actually do) a description of known bugs that apply to two or three different topics, and I would like to have a single place to update it (something that is easily done with the current %STARTINCLUDE% %STOPINCLUDE% directives), but what happens if we want different parts of the same file to be included in different topics?.

A way to do this would be to extend the %STARTINCLUDE% and %INCLUDE{}% syntax to contain section numbers or names i.e. In the source topic

% STARTINCLUDE{section="bugs"}%
 .....
% STARTINCLUDE{section="moreBugs"}%
 .....
% STARTINCLUDE{section="funnyStuff"}%
 ....
% ENDINCLUDE{section="bugs,funnyStuff"}%
 ....
% ENDINCLUDE%

the spaguettiny construction is intentional but I'm not sure that it would permit a clean perl implementation.

So in the destination topic an %INCLUDE{"source_topic", "bugs"}% would take the place of the conditionals. Or in the case that started this whole discussion %INCLUDE{"source_topic", %WEBPLUGINS%}% could take care of the problem, as long as the %WEBPLUGIN% dinamically generated variable is properly defined.

-- EdgarBrown - 27 Jun 2001

A co-worker and I discovered a way to get something like the ConditionalRendering to work with the 1Sep2001 and 1Dec2001 versions with no code changes!

Here's the problem we were trying to solve. We wanted to have two versions of information for display.

  1. Have a topic with software coding standards listed
  2. View the same topic with an example for each coding standard included immediately following each standard.
  • Note that if we didn't care about the example immediately following the text, we'd just have two pages: one for the standard, the other for the examples. Then we'd have a third that simply includes both the standard and the examples.

We have these topics:

  • CodingStandard - where all the requirements are listed
  • CodingStandardItem1Example - the example for the first item in the coding standard
  • CodingStandardItem2Example
  • until no more examples.

On the CodingStandard page, say item 1 is:

  1. Avoid the use of goto

Under item 1 on the CodingStandard page, we put these nested TWikiVariables such that TWiki will include text if a URL parameter is properly set:

%INCLUDE{"CodingStandardItem1%URLPARAM{"view"}%"}%

When you view the page normally, you only see the coding standard (no examples. This is because the URLPARAM variable will not be set to anything and TWiki will silently ignore the INCLUDE since that page doesn't exist.

If you add the URL parameter ?view=Example to the URL, the coding standard is displayed with the Examples. Each example is being included from its own CodingStandardItem*Example topic.

See the test/example I did at Sandbox.ConditionalInclude.

-- MikeBarton - 15 Jan 2002

It looks like the INCLUDE directive has a pattern matcher in it, so all you'd need to do would be use a certain style of demarcation in the page you're including from, and use a parameterized RE to pull it out. Or wouldn't that work (obvious I haven't tried it yet, its just an off the cuff idea).

Alternatively, the "?view=..." idea is nice, though I'd probably put the included bits into a separate web to keep the clutter down. How annoying that would make editing, I'm not sure.

-- DougPhilips - 04 Feb 2002

We just wandered into a vaguely related situation where some sort of ConditionalRendering would have been really helpful. In particular we created a TWiki web for discussion of books that we might want to order for our library. There's a simple textfield/button combo for creating a new book suggestion page, and that page has an attached TWikiForms with fields for title, author, ISBN, etc., etc. What we then wanted was a way to automagically pull out the key fields (title, author, ISBN, and price) and display them at the top of the page.

We can get the info out of the fields (although we have to use %SEARCH% since we're still using the December 2001 release); the trick is displaying them at the top. This is obviously easy enough: Just put the necessary search at the top of every page, along with a little markup, and you're set. And this isn't even terribly difficult because we use TWikiTemplates to provide a "starter page" for every book, and we can include the search and markup there. It would be nice, though, if it could just "show up" without the user seeing (or having the chance to mess with) it's generation.

The obvious thing to try next was TWikiSkins, and this is where we ran into the problem of ConditionalRendering. If all the pages in this web were these book pages, we'd be set, but they aren't all book pages. We have the home page that describes why the web is there and how people can/should use it, and we have a variety of search/summary pages that pull out things like recently added books, books that have been ordered but which haven't yet arrived, books recommended by a specific person, etc., etc. These don't have the form at the bottom with all the book info (since they don't represent a book), and if they're displayed with the skin, you get some weird layout ick at the top without any data.

One way to solve this would be to explicitly specify the skin (either for the books if the "regular" skin was the default, or for the non-book pages if the book skin was the default), but this isn't very satisfying and it's not terribly robust when people start linking to these pages (which we hope they will) since they're not likely to remember or want to have to add skin arguments to their links. Another approach would be to have all the book pages in one web, and the home and search/summary pages in another, but this seems pretty ugly as well.

A cool thing solution would be to to have ConditionalRendering, where the skin (or template or whatever) could "ask" whether this page had a book form associated with it, and only generate the book header if it did. It wouldn't need to be anywhere near as fancy as embedding Perl or PHP in the wiki code, just a simple IF would do the job. Perhaps something like an IF_DEFINED that checks to see if a variable is defined, and then add a FORM_NAME variable that is set to a page's associated form if there is one?

For now we'll probably just go with having the search and markup added to every page via the template, and just trust our users not to mess it up, and I'm pretty sure that will work just fine. ConditionalRendering would have been nice, though :->.

-- NicMcPhee - 20 Jun 2002

Have you tried using %URLPARAM%? This lets you insert parameters at least, which could be used to drive an include that then pulls in the right code for the book form. There are examples above as well as one in FormattedSearch and the source of WebSidebarMakerIE (used to generate customised registry values through TWiki).

Not very elegant but should be possible. Another approach would be to embed PHP or similar code in the TWiki page, and make sure that the CGI script output is then PHPed - however, that would be something of a security nightmare as every TWiki page would now be a PHP script...

-- RichardDonkin - 21 Jun 2002

We had a similar case. What we came up with is a one line INCLUDE at the top of the topic. The included text does the search magic based on INCLUDINGTOPIC. That way users see just one line of text at the top, which is better then several lines of cryptic FormattedSearch text.

-- PeterThoeny - 21 Jun 2002

What if we add new keyword, like %SKIN{'skinname'}%, and TWiki will override default skin for this page only, and render it accordingly? Will be this too complicated to implement? And definitely it will add flexibility...

-- PeterMasiar - 21 Jun 2002

Along the lines of EdgarBrown's idea (see way above) I've created a plugin which adds conditional rendering functionality in a relatively secure manner. Please see ConditionalPlugin for details.

-- JeroenVanDongen - 10 Aug 2002

A php or Velocity based approach is better in long term - they have matured w.r.t. managing dynamic data for web bages. In short term, plug-in based approach is OK.

There is another way to think about rendering: Think of rendering in different layers. The lowermost layer is the raw data that is stored on disk file. The first layer is what you get after basic processing: INCLUDE, SEARCH etc. The next layer is what the plug-in's may introduce, and the final layers do the SKIN and other page-specific rendering. (The plug-ins should register themselves at a particular level.) So, the php- or velocity- rendering layers are introduced by the selected skins to give the final view.

I wanted this feature because I am thinking about Structural editing (i.e. attaching editing buttons for each element of the document (a list, table and a paragraph). And with this thinking, it will be just below the "View" layer (with no editing buttons - including the buttons that show up with EditTablePlugIn). And when you hit an edit view you go to the "Edit" view page to select a specific structural element. If you didn't have this layer, then you would go to the normal "Edit" window.

(The same feature also helps me in putting portal pages - the pages that integrate information from multiple other pages.)

-- VinodKulkarni - 12 Aug 2002

Although I can see where you're coming from, I would personally think of this as both a violation of the KISS principle and you're creating a potential security disaster. In case you want structural editing (which by itself is a GoodThing imho), I'd rather go for a scheme where one can identify different blocks in a topic with a simple marker which tells which plugin to call to render this block. This way you stay very close to the way TWiki currently works, and pages stay readable to the naked eye.

An example topic could look like: %SECTION{"WikiMLPlugin"}% .... some content ... %ENDSECTION% %SECTION{"EditTablePlugin"}% .... table1 .... %ENDSECTION% %SECTION{"EditTablePlugin"}% .... table2 .... %ENDSECTION%

or on a portal page:

%SECTION{"SlashBoxPlugin"}% .... search statement to fill the slashbox .... %ENDSECTION%

In view-mode the plugin's would generate multiple 'edit' buttons on the page, around the sections. When such an edit button is clicked on, that specific section is extracted and rendered for editing by the indicated plugin. Guess this depends on the extended plugin API to become possible, but it seems to me a nicer solution to your problem than including another scripting language.

-- JeroenVanDongen - 12 Aug 2002

Interesting, Jeroen's proposed syntax predates the NamedIncludeSections syntax by one year.

-- PeterThoeny - 27 Aug 2003

Gosh! eek! Wow! confused Wonder where I got the idea for the syntax from? smile wink

    • The author of the conditional rendering plugin suggested the use of a %SECTION% tag.
    • The TocPlugin also uses a section tag, but of the form %SECTIONN% along with 3 other tags.
    • The standard %TOC% tag denotes implicit sections delimited by header tags.
    • The SectionalEditPlugin defines an XML-like tag for denoting divisions between sections (ala <hr>), but limits the use of these tags for denoting sections that can be editted. Whilst these sections are edittable, they aren't includable.

    -- From NamedIncludeSections

Bullet item 2 is the reason for having a depth attribute in the original proposed syntax - which extends the syntax mentioned above due to having attributes on the close portion as well as on the beginning. (And very useful it is too) However out of the three whilst the first is the easiest to implement, the third is the most user friendly, more in keeping with the Wiki Way, and needs work.

Oh, and 12 August 2002 to 10 June 2003 (specification, first blush implementation was 14 Jun 2003 I make 10 months, not a year, but it's not really much different smile

smile

-- MS - 27 Aug 2003

Retrospective:

  • After several months of using this syntax I've come to the conclusion that whilst extremely useful, taking sections based on a DOM and hence more a fine grained addressing approach would be significantly useful.
  • I've so far not found any need for the depth attribute, and hence it's not been implemented
  • Named sections are useful, but it would be useful to be able to give multiple sections the same name (and from a DOM basis, the same level) for pulling in to another document. (Slideshow plugin for example would be simplified)

-- MS - 19 Dec 2003

Edit | Attach | Watch | Print version | History: r25 < r24 < r23 < r22 < r21 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r25 - 2003-12-19 - MichaelSparks
 
  • 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.