Item15172: RenderWikiApplicationWebHome does not list all topics
Priority: Normal
Current State: New
Released In: n/a
Target Release: n/a
--
BramVanOosterhout - 09 Jan 2023
Applications.RenderWikiApplicationWebHome is meant to list all topics relevant to an application if the ?q= parameter is not supplied. The current implementation does not list any topics. This caused by line 45:
query="%IF{"'%URLPARAM{"q"}%'!=''" then="TopicType=~'%URLPARAM{"q"}%'" else="topic='.*'"}%"
The topic parameter is not valid as part of a query in a DBCache context. I believe the correct query is:
query="%IF{"'%URLPARAM{"q"}%'!=''" then="TopicType=~'%URLPARAM{"q"}%'" else="TopicType=~'.*'"}%"
The following patch fixes the problem.
--- a/data/Applications/RenderWikiApplicationWebHome.txt
+++ b/data/Applications/RenderWikiApplicationWebHome.txt
@@ -1,4 +1,4 @@
-%META:TOPICINFO{author="ProjectContributor" comment="" date="1556788680" format="1.1" version="1"}%
+%META:TOPICINFO{author="BramVanOosterhout" comment="" date="1673256078" format="1.1" reprev="2" version="2"}%
%META:TOPICPARENT{name="TopicFunction"}%
%TOC{depth="2"}%
@@ -42,7 +42,7 @@ See the [[CompleteDocumentation]].
%DATATABLE{
class="foswikiFlatTable foswikiStripes"
- query="%IF{"'%URLPARAM{"q"}%'!=''" then="TopicType=~'%URLPARAM{"q"}%'" else="topic='.*'"}%"
+ query="%IF{"'%URLPARAM{"q"}%'!=''" then="TopicType=~'%URLPARAM{"q"}%'" else="TopicType=~'.*'"}%"
web="%BASEWEB%"
columns="index,TopicTitle,Summary,TopicType,WikiApplication,Changed"
rows="10"
That's not correct. We want to list all topics, not only those with a
TopicType. The
topic
parameter is indeed very valid.
A better fix is to remove the else part all together.
--
MichaelDaum - 09 Jan 2023
Tried that
removing
else="TopicType=~'.*'"
gives strange results. Some topics are omitted from the list. This:
%DATATABLE{
class="foswikiFlatTable foswikiStripes"
query="%IF{"'%<nop>URLPARAM{"q"}%'!=''" then="TopicType=~'%<nop>URLPARAM{"q"}%'"}%"
web="Applications"
columns="index,TopicTitle,Summary,TopicType,WikiApplication,Changed"
rows="10"
searching="on"
lengthmenu="5,10,20,30,50,100"
info="off"
paging="on"
sort="Changed"
reverse="on"
width="100%"
savestate="on"
}%
produces 8 pages of results. Page 1 shows results 1..8, Page 2 15..19, Page 3 22 .. 30, etc... It appears some results get lost altogether.
Two rhetorical questions:
1. if topic is a valid query parameter, why does it not work?
2. why such weird results if the else is deleted?
Could the problem be in
JQDataTablesPlugin?
Let me investigate.
.
--
BramVanOosterhout - 10 Jan 2023
I did some investigation and the conclusion is:
Summary
The problem is between the seat and the keyboard
Question: Can I add
connector="dbcache"
to the
RenderWikiApplicationWebHome DATATABLE
parameters. The
WikiWorkbench
requires
DBCachePlugin
anyway.
Re: the missing entries in the displayed list: that is a feature. Topics without a
FORM
are skipped, but the index is incremented regardless.
Long answer
the connector
Analysis:
The wiki workbench is shipped with the DATATABLES query:
query="%IF{"'%<nop>URLPARAM{"q"}%'!=''" then="TopicType=~'%<nop>URLPARAM{"q"}%'" else="topic=~'.*'"}%"
The query is connector specific (dbcache) in the
topic=~'.*'"
part. The
JQDataTablesPlugin
installation sets the default connector to
search
(Well I did).
And
topic=~'.*'"
returns no result with the
search
connector.
So no bug.
The fix for me is to add the
connector="dbcache"
to the DATATABLE in
RenderWikiApplicationWebHome
, since I have used the
DATATABLE
default connector in many other places, with the associated query
SEARCH.
Adding the connector to the
RenderWikiApplicationWebHome DATATABLE
parameter list in the distribution would avoid the confusion for other users. Here is the patch:
diff --git a/data/Applications/RenderWikiApplicationWebHome.txt b/data/Applications/RenderWikiApplicationWebHome.txt
index a5f2b3c..7051521 100644
--- a/data/Applications/RenderWikiApplicationWebHome.txt
+++ b/data/Applications/RenderWikiApplicationWebHome.txt
@@ -1,4 +1,4 @@
-%META:TOPICINFO{author="ProjectContributor" comment="" date="1556788680" format="1.1" version="1"}%
+%META:TOPICINFO{author="BramVanOosterhout" comment="" date="1673657914" format="1.1" version="4"}%
%META:TOPICPARENT{name="TopicFunction"}%
%TOC{depth="2"}%
@@ -43,6 +43,7 @@ See the [[CompleteDocumentation]].
%DATATABLE{
class="foswikiFlatTable foswikiStripes"
query="%IF{"'%<nop>URLPARAM{"q"}%'!=''" then="TopicType=~'%<nop>URLPARAM{"q"}%'" else="topic='.*'"}%"
+ connector="dbcache"
web="%BASEWEB%"
columns="index,TopicTitle,Summary,TopicType,WikiApplication,Changed"
rows="10"
Alternative: Add a note in the description that says:
The query used in the
DATATABLE
requires the
dbcache
connector. If this is not your default connector (set in
config JQDataTables
), you need to make it explicit here with
connector="dbcache"
The missing entries in the listed topics
Analysis:
The missing entries are related to topics in the web that do not have a
FORM
associated with them. Specifically:
No formdef: Topic=WebAtom
No formdef: Topic=WebChanges
No formdef: Topic=WebLeftBar
No formdef: Topic=WebLexiconTemplate
No formdef: Topic=WebLinks
No formdef: Topic=WebNotify
No formdef: Topic=WebPreferences
No formdef: Topic=WebRss
No formdef: Topic=WebSearch
No formdef: Topic=WebSearchAdvanced
No formdef: Topic=WebTopicEditTemplate
No formdef: Topic=WebTopicList
That makes sense, because there are no fields other than
Changed
to display.But it is weird that the numbering is not adjusted.
Investigation:
Topics without a form definition are skipped in =FoswikiConnector.pm - convertResult (line 188).
For a freshly created app
DBCacheConnector search
returns (line 408)
- Total 26
- Total filtered 26
- Entry count in @data 17
The display from
RenderWikiApplicationWebHome
contains 17 entries numbered 1 .. 26. Nine entries( 13, 14, 15, 17, 18, 20, 21, 23,24) are missing.
The rowNumber is set in
FoswikiConnector.pm - convertResult
(line 223) as
$params{index}
.
$params{index}
is set to
$index
in a loop over
all matched topics.
$index
is incremented for
each topic. (
DBCacheConnector
line 389)
And so each $row goes up one number. However...
... since convertResults skips topics without FORM and therefor does not increment
$count
,
convertResult
will return
undef
for these topics (line 388). In turn these non-rows are not pushed to
@data
(
DBCacheConnector
line 402).
But the index is still incremented.
Question convertResults deliberately removes topics without a FORM. Should it?
If so, the index needs to be adjusted.
If not, the non-FORM topics should not be skipped.
Which way should it be?
--
BramVanOosterhout - 14 Jan 2023