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.
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.
--
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
- This needs to be added to the documentation of IfStatements, because it is too easy to overlook - Tasks.Item854
- 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:
- Making search work with result sets,
- Replacing other crap hacks (such as %META, %FORMFIELD, %METASEARCH) with somethnig cleaner based on SEARCH,
- Supporting better forms (multiple forms in a topic, mixins, etc),
- 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