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:

%INCLUDE{"ActivityInclude"}%

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?

Thanks

-- 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