New Foswiki release 2.1.6 is available with important security fixes.
Sourceforge foswiki email lists being discontinued. Subscribe to the new Foswiki announce and discuss lists at MailingLists
This question about Topic Markup Language and applications: Answered

INCLUDE and URLPARAM cause fragile apps. How can this be avoided?

I'm developing an application where each topic is basically a database entry with an attached form. It is also a display and update point. It generates a table via search. (It also includes options to create another database entry, but that's not relevant here).

To ease maintenance the topic itself should ideally contain a single include:
Where ActivityInclude contains all the search and display logic. That way I can enhance the application at any time by updating ActivityInclude.

The specific problem with this is that some search parameters can
%INCLUDE{"ActivityInclude" Types="%URLPA%NOP%RAM{"Types" multiple="on" separator="|"}%" State="%URLPA%NOP%RAM{"State" default="OPEN" multiple="on" separator="|"}%" Actor="%URLPA%NOP%RAM{"Actor" multiple="on" separator="|"}%" Rank="%URLPA%NOP%RAM{"Rank" multiple="on" separator="|"}%" Priority="%URLPA%NOP%RAM{"Priority" multiple="on" separator="|"}%" Changes="%URLPA%NOP%RAM{"Changes" default="999"}%"}%
be changed by the user and I need to pick up =URLPARAM=s to pick up changes.

However, ActivityInclude cannot use the URLPARAM macro. I am forced to creating each database entry with a template like below: This creates a seriously fragile application. If I need to change the search options then I would have to write code to scan all existing database entries and update the INCLUDE statement.

Is there a way I can use URLPARAM successfully from within INCLUDE? Is this restriction a deliberate security feature?

-- JulianLevens - 03 Sep 2009

Just by asking this question made me reconsider my design and I realised that the right way to do this is to have a single page which is passed the relevant topic (i.e. database key) and then use this to generate the output. It did not take long to create such a page basically hacking ActivityInclude to add some set statements for URLPARAMs and also replace all references to %<nop>INCLUDINGTOPIC% with %<nop>Act% which was a newa URLPARAM for the task.

I went in the original direction about two years ago in my early forays into TWiki applications and it does work, but its fragile. I found this direction natural because of the autolinking. Indeed I need to enhance my ActivityInclude to create links to further Acts which now come back to ActivityInclude with Act as a parameter. Now, what's the best way to create such a link (and there are sometimes many in a list)?

And I am still curious if this URLPARAM restriction (not ok in INCLUDE) is deliberate?


-- JulianLevens - 03 Sep 2009

After further work I realise another reason couple of reasons why I went down my original design route:
  1. Jumping to a particular database topic works fully – you do not just view the form but the application show related topic automatically
  2. Similarly, the autolinking of my database topics works without extra effort
    • At least my app is not fragile now and I can do this in one place
    • If the app works well will the user ever jump directly to a database topic?
      • Does it really matter if the topic does not automatically bring up the application?
My options are:
  1. Don't worry about it
    • The user will come into the application by default and click links to other entries
    • Possibly add a special jump box onto the app screen
    • Possibly add a link within the raw topic back to the app with self as a parameter
    • Con: Lack of autolink is a problem when referencing database topic in other topics
      • Can this be fixed with combination of the AliasPlugin and InterWikis?
        • Experiments say no, but interwiki is useful to enable simpler user links like \[\[Act:nnnn]] but it's not autolinking ideally to get the best user interface – trade-offs, trade-offs!
  2. REDIRECT the database topic to the app with self as a parameter?
    • Pro: Fixes both problems
    • ConPro: REDIRECT Plugin does not support params
    • Con: pollutes the standard topic text, which is now clear for user's use after above design changes
      • Or can I hide this as METADATA (without needing to write a plugin)?
  3. Some other redirect intercepting jump box or view script?
    • Con: Not sure how to do this
    • Con: Suspect pitfalls and probably ugly
Option 1 is favourite

If each db record has a form attached, you can use AutoViewTemplatePlugin to apply a special template that either overlays your application instead of the default view, or offers a link with appropriate parameters to the application topic. This way you don't have to manually plant links in the topic text, let the templates do it for you.

-- PaulHarvey - 20 Apr 2010

QuestionForm edit

Subject Topic Markup Language and applications
Version TWikiRelease04x01x01
Status Answered
Topic revision: r5 - 20 Apr 2010, PaulHarvey - This page was cached on 18 Sep 2018 - 01:25.

The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy