Feature Proposal: add web and .topic to the Query Search language

Motivation

"form.name ~ '*.UserForm'" is really poor.

"topic(form.name) = 'UserForm'" would make more sense.

which I think PaulHarvey has mentioned in a Foswiki::Address related proposal

Description and Documentation and examples

Add topic() and web() functions to the query (IF,SEARCH,QUERY....) language.

• web('System.InstalledPlugins') == 'System'
• topic('System.InstalledPlugins') == 'InstalledPlugins'

• it probably makes sense for web('noDotString') to return undef/zero/emptystring
  • though it could be argued that =web('ExistingWebThatTheUserHasPermissionToSee') might return that web (I don't think so though)
• it probably makes sense for topic('noDotString') to return 'noDotString' irrespective of the topic's existance in the current web

and considering the reason for this proposal,

• its _probably sensible for web('nonExistantWeb.NonExistantTopic') to none the less return the string 'nonExistantWeb', as the topic with the form may have been copied from some other wiki

Given a topic 'Abc/Def.Ghi', you can assume:

1. topic('Abc/Def.Ghi') = Ghi
2. web('Abc/Def.Ghi') = Abc/Def
3. topic(web('Abc/Def.Ghi')) = Def
4. web(web('Abc/Def.Ghi')) = Abc
5. web('Ghi') = the 'current' web
6. topic('Ghi') = Ghi
7. web('') = ''
8. topic('') = ''

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- Contributors: SvenDowideit - 24 Feb 2012

Discussion

Hmm, ok, interesting; the spec needs some refinement, what does topic actually do? How does 'AnotherTopic'/[topic(form.name)='UserForm'] work?

Or should it perhaps be 'AnotherTopic'/[topic(form.name)=topic('UserForm')] (which is deeply nasty)

Or perhaps 'AnotherTopic'/[form.name issametopic 'UserForm'] ?

-- CrawfordCurrie - 24 Feb 2012

ok, lets start by rejecting issametopic outright. The querylanguage is useful for both IF/SEARCH but also important for QUERY so its more useful to be able to get the separation.

And thus I also reject the much less useful name.topic style and also go with the topic('text') function.

updating above.

-- SvenDowideit - 24 Feb 2012

So what we have here is basename and dirname. OK, so there's no way to determine if the form is in a particular web or not (the form field in a topic stores only the name of the topic, not the web). Are you anticipating nesting these? If you could, then finding the parent web of a subweb becomes interesting....

Still concerned.

-- CrawfordCurrie - 24 Feb 2012

can you elaborate? I don't understand what you're saying above - my proposal basically recognizes that we're doing a regex query because there is no TML equivalent to normaliseWebTopic.

additionally - the form field does store web and topic - this is why the example given in QuerySearch uses the example listed above (which is also not entirely correct, because we store the form name extremely inconsistently - and was the initial reason for the proposal, but now I realise that being able to consistently get a topic($formfield(Reference)) is actually much more useful than the $pattern mess we'd need to use to get it otherwise.

-- SvenDowideit - 25 Feb 2012

I'm trying to understand/flesh out the spec. Given a topic 'Abc/Def.Ghi', can I assume:

1. topic('Abc/Def.Ghi') = Ghi
2. web('Abc/Def.Ghi') = Abc/Def
3. topic(web('Abc/Def.Ghi')) = Def
4. web(web('Abc/Def.Ghi')) = Abc
5. web('Ghi') = the 'current' web
6. topic('Ghi') = Ghi
7. web('') = ''
8. topic('') = ''

If not, what should I assume?

-- CrawfordCurrie - 25 Feb 2012

See also Tasks.Item10484

-- PaulHarvey - 26 Feb 2012

Crawford - yes, exactly - Foswiki::Func::normaliseWebTopicName() without the defaulting to 'Main', 'WebHome'

• I moved my test set up to the spec and removed my concern - CC

-- SvenDowideit - 09 Mar 2012

Changed to parked - needs a developer

-- GeorgeClark - 08 Feb 2016