Feature Proposal: Add "OR" relation to macro FORMFIELD

Motivation

It is now quite impossible (without FormFieldListPlugin) to list form fields values where multiple form field names can occur. Take our current site. Support web uses TopicTitle, Tasks web uses Summary, and to show these titles/summaries in a SEARCH is impossible. What would be needed is "TopicTitle OR Summary".

Description and Documentation

Enhance the fieldname parameter with OR notation (pipe character):

%FORMFIELD{"fieldname_1|fieldname_2|fieldname_n" topic="topic"}% 

Examples

%FORMFIELD{"TopicTitle|Summary" topic="topic"}% 

Impact

We can assume no pipes are used in form field names, as this would break the topic form table.

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- Contributors: ArthurClemens - 23 Jan 2009

Discussion

That's a useful extension. Isn't there an easy way to use %IF for it? Anyway, I'd be happy to see TopicDisplayName and UserExperienceProjectPageTitle being resolved as well which is the actual cause for this proposal, isn't it.

• It does not work on the site because we could not install DBCachePlugin. -- ArthurClemens - 23 Jan 2009

-- MichaelDaum - 23 Jan 2009

To use %IF you'd have to %FORMFIELD{"%IF{"defined topic/fieldname_1" then="fieldname_1" else="fieldname_2"}%" topic="topic"}% Not hard, but not exactly elegant either.

• I cannot get that syntax to work. Its new to me and not documented, so I am rather in the dark. -- ArthurClemens - 23 Jan 2009

I have a general concern about all these one-off solutions to meta-data referencing problems. They need to be designed with reference to a consistent content access syntax, or we'll end up with a plethora of incompatible point solutions.

-- CrawfordCurrie - 23 Jan 2009

Sorry for the aside, but it is documented. I didn't look at the doc and got it slightly wrong, but the '/' operator has been in %IF since we added querysearch. Some examples:

• %IF{"'AddMetaSetActionToEditAndSave'/CurrentState" then="ok" else="bad"}% returns ok
• %IF{"'AddMetaSetActionToEditAndSave'/ChipsAndBeans" then="bad" else="ok"}% returns ok

-- CrawfordCurrie - 24 Jan 2009

1. This needs to be added to the documentation of IfStatements, because it is too easy to overlook - Tasks.Item854
2. The syntax does not work with underscore topic names, like Test_post_with_summary - Tasks.Item855

-- ArthurClemens - 24 Jan 2009

Still, the IF construct is very difficult to use (and time consuming to get it right) for more than 2 cases.

To address Crawford's concern: to make the access syntax consistent, we would use query syntax, right? For example:

%FORMFIELD{"'TopicTitle' OR 'Summary'" topic="topic"}% 

-- ArthurClemens - 24 Jan 2009

I'd like to suggest we change tack. the IF syntax is difficult and annoying specifically because you can't simple ask Foswiki to display the results. Similarly, FORMFIELD is a hacky separation from INCLUDE so why not make INCLUDE, FormatedSearch do the job.

ie,

the value of FormStatus

Web.topic/section['sectionname'].value

not yet implemented in IF, but also needed - a topics' named section

%INCLUDE{"Web.topic/section['sectionname'].value"}%

There are variations and improvements that are possible for the syntax, but the main thing is that if a user can see what the QuerySearch nodes' values are, they can grasp what is going on faster. At the same time, we can start deprecating some of the redundant syntaxes.

To relate this back to the main suggestion - I would also like some ability to do OR's for INCLUDE - but i don't just want it topic based, I'd want it for sections too

ie

%INCLUDE{"Web.topic/section['sectionname'].value | Web.topic/section['sectionname'].value | SomeEntireTopic"}%

further brainstorming: To extend the concepts though, we may well be deprecate not just FORMFIELD, but INCLUDE as well, as the above is basically just a SEARCH by replacing the idea of topic="" with non-topic result sets:

in this case, the inputs to the SEARCH that will be tested are the text values of Web.topic/section['sectionname'].value, Web.topic/section['sectionname'].value, SomeEntireTopic

%SEARCH{
    input="Web.topic/section['sectionname'].value, Web.topic/section['sectionname'].value, SomeEntireTopic"
    search="defined($text)"
    format="$text"
    limit="1"
}%

Perhaps a different macro name would work better, but internally, FORMFIELD, INCLUDE, SEARCH and so on would be implemented internally using the same code - TOM to specify the items to test, Query statements to test, and format to display

And the best thing is, this functionality should be easy to make happen by using the ExtractFormat feature and the ResultSet feature.

-- SvenDowideit - 25 Jan 2009

Thinking about INCLUDE in terms of SEARCH is very useful. INCLUDE is indeed a special case of SEARCH, as is FORMFIELD. As you expressed it above, you want to be able to INCLUDE one of several fields, depending on which is available from the topic. This is a function of the output side of a search, not part of the search itself, so overloading the query syntax is the wrong approach. The syntax you want to overload is the format syntax; perhaps something like this:

%INCLUDE{"Web.topic" format="$formfield(fieldname_1|fieldname_2|fieldname_n)"}%

The reason I like this is that it's a natural extension point given ExtractAndCentralizeFormattingRefactor. And the idea of providing:

%INCLUDE{"Web.topic" format="$section(intro|summary|thesis)"}%

and getting

%SEARCH{"TopicClassification='Document'" format="$title: $section(intro|summary|thesis)"}%

"for free" is highly attractive.

-- CrawfordCurrie - 25 Jan 2009

I dissagree :/

by adding | to $section etc, we would create yet another selection language.

Also, in the suggested form, you are arbitrarily limiting the new selection operator to items of the same time - on the same topic.

thirdly, I'm not sure I have ever seen a print statement in a language that contains a formatting operator that does logic - they all just format items selected using logic - so I think adding | is mixing concerns.

IMO, TOM addressing is what we should be using in ResultSets (it is my hope that I can make ResultSets not be a list of topics, but rather a list of nodes (fields, forms, sections, topics or even maybe webs) that can then be filtered, combined and manipulated (using the query language) and then formatted for output.

%SEARCH{
    input="Web.TopicOne/section['sectionname1'], Web.TopicTwo/section['sectionname2'], Web.YetAnotherTopic/field[name ~ '*.Status'], SomeEntireTopic"
    search="defined($value)"
    format="$value"
    limit="1"
}%

or in the longer separated out form (ie, both should give the same result)

%RESULTSET{
    input="Web.TopicOne/section['sectionname1'], Web.TopicTwo/section['sectionname2'], Web.YetAnotherTopic/field[name ~ '*.Status'], SomeEntireTopic"
   name="TryThese"
}%
%SEARCH{
    inputset="TryThese"
   outputset="These"
    search="defined($value)"
}%
   * ok, the limit="1" could potentially be in either, in another ResultSet manipulator or, whatever - 
%FORMAT{
   inputset="These"
    limit="1"
    format="$value"
}%

I was going to try to render the above into a format= based syntax, but i gave up - no coffee yet

Arthur - sorry for hijacking your simpler proposal - its wonderful to see that the needs I am wanting to address in ResultSet and ExtractAndCentralizeFormattingRefactor already have usecases

Note also that Michael and I were discussing a similar thing in a Task - we'll go find it and add that info here too

-- SvenDowideit - 25 Jan 2009

No problem, but it is obvious I can no longer be commited developer. And in any case this topic will be superseded by the more general TOM proposals. Looking forward!

-- ArthurClemens - 25 Jan 2009

Arthur's right, this is way beyond the original proposal. We need to focus on what's proposed a bit better. Right now I feel we're still nibbling at the edges of this problem. There are a number of related concerns:

1. Making search work with result sets,
2. Replacing other crap hacks (such as %META, %FORMFIELD, %METASEARCH) with somethnig cleaner based on SEARCH,
3. Supporting better forms (multiple forms in a topic, mixins, etc),
4. Keeping it all simple and clean enough for a normal person to be able to use it.

These concerns touch an awful lot of code. Task-team time?

BTW Sven, one thing that bothers me is that the query search language is too obscure for many people. Yes, I know that we need something with that sort of expressive power, but in order to do that we are forced to create a language that is unfriendly to some people. I have learned the hard way that very few people have been able to intuit the FormQueryPlugin, which has supported query searches and result sets for years.

The idea behind using the pipe operator in the output is that it is reasonably intuitive. This is rather like the argument between Perl and real programming languages - if you want to do "the right thing" you use a proper language, but if you are in a hurry or just don't know any better, Perl does the job. Well, the pipe operator does the job with very little additional excise on the user. Note that the search query language doesn't have a selector that allows you to select between different fields (yes, we could overload OR in the truly obscure, sh-ish way that perl does - but it's really obscure for most folks)

-- CrawfordCurrie - 26 Jan 2009

3 years later, I rejected this proposal.

-- CrawfordCurrie - 21 Feb 2012