New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add SMWSearch power profile form #3126

Merged
merged 1 commit into from Apr 22, 2018

Conversation

Projects
None yet
4 participants
@mwjames
Copy link
Contributor

mwjames commented Apr 14, 2018

This PR is made in reference to: #1233

This PR addresses or contains:

  • Adds a smw power form to Special:Search for when $wgSearchType = 'SMWSearch'; is used

This PR includes:

  • Tests (unit/integration)
  • CI build passed

Fixes: #1233

Example

image

@mwjames

This comment has been minimized.

Copy link
Contributor

mwjames commented Apr 14, 2018

@kghbln @s7eph4n This is a WIP and came as left-over while experimenting with ES on excerpts and score sorting.

The power form adds some sorting Best Match, Most Recent... in order for results to be sorted differently. Of course, "Best Match" only makes sense in connection with ES where we get scores and can sort them accordingly.

Questions:

  • Do we want or need something like this in core?
  • Currently, the profile is called Extended any better name for such profile?
@kghbln

This comment has been minimized.

Copy link
Member

kghbln commented Apr 15, 2018

Do we want or need something like this in core?

I believe that this is a nice feature especially for power-users or users who are desperate to find something a grab every straw to get something useful as results. Probably depending on the effort to make it happen.

Currently, the profile is called Extended any better name for such profile?

I am wondering if this could "also" be piggy-backed to the "Advanced" tab like Translate and/or SIL are doing it. Apart from that "Extended" appears fine to me.

@mwjames

This comment has been minimized.

Copy link
Contributor

mwjames commented Apr 15, 2018

I am wondering if this could "also" be piggy-backed to the "Advanced" tab like

Well, there is a side story to the "Advanced" tab which can be extended with a hook called SpecialSearchPowerBox and as SIL has tried it is pretty much useless as soon as you click the paging >> button because the hook is missing a vital piece that would allow you to set your optional parameters (SpecialSearch::setExtraParam) so that they can be retained beyond the first page.

The "Advanced" tab and SpecialSearchPowerBox hook in MW-core could be fixed by allowing parameters to be transferred as in:

@@ -269,17 +269,21 @@ class SearchFormWidget {
 		}
 
 		$showSections = [
 			'namespaceTables' => "<table>" . implode( '</table><table>', $namespaceTables ) . '</table>',
 		];
-		Hooks::run( 'SpecialSearchPowerBox', [ &$showSections, $term, $opts ] );
+		Hooks::run( 'SpecialSearchPowerBox', [ &$showSections, $term, $opts, &$parameters ] );
 
 		$hidden = '';
 		foreach ( $opts as $key => $value ) {
 			$hidden .= Html::hidden( $key, $value );
 		}
 
+		foreach ( $parameters as $key => $value ) {
+			$this->specialSearch->setExtraParam( $key, $value );
+		}

Above is not going to happen and your left with creating your own tab via SpecialSearchProfileForm, copy the whole NS select form from the "Advanced" tab (seriously what a waste), and add your own form parameters to function correctly.

@s7eph4n

This comment has been minimized.

Copy link
Contributor

s7eph4n commented Apr 15, 2018

I love it! Frankly, I am surprised that this is not a thing yet on the vanilla search.

Do we want or need something like this in core?

Yes, if you ask me. I think modularity is great, but users are already complaining about the complexity of the installation. So until we have a better way of installing extensions I'd go for including it directly.

Currently, the profile is called Extended any better name for such profile?

Would it be possible to not have it as a new profile, but as an additional option to all the other profiles? Sort order and search perimeter are orthogonal.
(Ok, just read your answer. What a shame. 👎 )

@mwjames

This comment has been minimized.

Copy link
Contributor

mwjames commented Apr 15, 2018

Would it be possible to not have it as a new profile, but as an additional option to all the other profiles? Sort order and search perimeter are orthogonal.

I'd love to but see my comments on the issue that arises with SpecialSearchPowerBox. It would reduce the entire section to something like:

public function newSpecialSearchPowerBox( &$showSections, $term, $opts, &$parameters ) {

	$sort = $GLOBALS['wgRequest']->getVal( 'sort' );
	$parameters['sort'] = '';

	$html = '';

	foreach ( [ 'foo' => 'Foo', 'bar' => 'Bar' ] as $key => $value ) {
		$selected = '';

		if ( $sort === $key ) {
			$selected = 'selected';
			$parameters['sort'] = $key;
		}

		$html .= "<option value='$key' $selected>$value</option>";
	}

	$showSections['smw-sort'] = '<select name="sort">' . $html . '</select>';
	$parameters['profile'] = 'advanced';
}
@mwjames

This comment has been minimized.

Copy link
Contributor

mwjames commented Apr 21, 2018

I understand that adding such profile is expedient for a user engagement, yet just having it for the sake of a sorting option seemed a bit exaggerated to justify the extra coding and hook complexity.

So, I pulled my magic hat over the last couple of hours to make this profile a meaningful endeavour by helping users to find things quick and easy. Saying that means, the profile is adding a form builder that let users define what search fields are relevant and provide a better existential means for the profile. To keep complexity low and the interface lean, fields are conjunctive which means if you need an OR, use the big long input field at the top with the well known [[ ... :: ...]] syntax.

The form builder uses a JSON definition [0] to define what property fields are to be displayed and in which order, whether they should have value autocompletion support or not, and so forth. The builder will create a HTML form that has a responsive design factor and is without any dependency to any other extension.

Why all this? SMW is mostly concerned with structured searches but combining them with a full-text search (as in case of ES) posses some challenges to find a simple interface. The complexity of Special:Ask might be overwhelming when you just need to find something and the new extended profile should allow novice as well as expert users to enjoy SMW's power search while freeing ourselves from support of a specific use case where users define their own search forms with the help of an extendable JSON schema.

It should enable users to provided different forms from within Special:Search without compromising the power of SMW and its selected query engine.

Form and definition

image

Definition

{
    "forms": {
        "Books and journals": [
            "Has title",
            "Has author",
            "Has year",
            {
                "Publication type": {
                    "autocomplete": true,
                    "tooltip": "Mandatory field, please select a type of publication because ...",
                    "required": true
                }
            },
            {
                "Publisher": {
                    "autocomplete": true
                }
            }
        ]
    }
}

Responsive form

image

JSON

Attributes Values Description
autocomplete true, false whether the field should add a autocomplete function or not
tooltip text or msg key shows a tooltip with either a text or retrieves information from a message key
placeholder text shown instead of the property name
required true, false whether the field input is required before submitting
type HTML5 preselect a specific type field

@mwjames mwjames referenced this pull request Apr 21, 2018

Merged

Add API `pvalue` browse module + autocompleter, refs 3126 #3129

2 of 2 tasks complete
@kghbln

This comment has been minimized.

Copy link
Member

kghbln commented Apr 21, 2018

Were do you get all these cool ideas. Show me the place please. :) And the definition of the search templates is done in the "rule" namespace!?

@s7eph4n

This comment has been minimized.

Copy link
Contributor

s7eph4n commented Apr 21, 2018

Wow! This is great!
Would it make sense to find some name other than "Extended", something that hints more at the functionality?

@kghbln

This comment has been minimized.

Copy link
Member

kghbln commented Apr 21, 2018

Would it make sense to find some name other than "Extended", something that hints more at the functionality?

Perhaps "Structured" as in structured content. This will definitively make people curious even if they do not know what it means right away.

@mwjames mwjames force-pushed the search-profile branch from bcae0af to 4ca511d Apr 22, 2018

@mwjames

This comment has been minimized.

Copy link
Contributor

mwjames commented Apr 22, 2018

templates is done in the "rule" namespace!?

First I had it as MediaWiki... but since you mentioned it, I created a new rule type and the definition is now expected at Rule:Search-profile-form-definition. The name is fixed, well you could go all willy nilly and search for all forms with the SEARCH_FORM_DEFINITION_RULE type but that's just too ...

I didn't spent too much time on the JSON schema but you got one rudimentary with search-form-definition-rule-schema.v1.json

Perhaps "Structured" as in structured content.

Currently it is maintained with "smw-search-profile": "Extended", and given that it is a msg key it can be easily renamed. If you think "Structured" is the term that makes a difference or for that matter any other term, go ahead.

@mwjames mwjames merged commit adc9e11 into master Apr 22, 2018

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details

@mwjames mwjames deleted the search-profile branch Apr 22, 2018

@mwjames mwjames added this to the SMW 3.0.0 milestone Apr 22, 2018

@kghbln kghbln referenced this pull request Apr 22, 2018

Merged

Add SMW_NS_RULE ns, refs 2273 #3019

2 of 2 tasks complete
@kghbln

This comment has been minimized.

Copy link
Member

kghbln commented Apr 22, 2018

@kghbln

This comment has been minimized.

Copy link
Member

kghbln commented Apr 22, 2018

First I had it as MediaWiki... but since you mentioned it, I created a new rule type and the definition is now expected at Rule:Search-profile-form-definition. The name is fixed, well you could go all willy nilly and search for all forms with the SEARCH_FORM_DEFINITION_RULE type but that's just too ...

Great. Still I have to dig into the mechanics of the new rule system since I am currently not sure how to set up more than one search template per wiki.

Currently it is maintained with "smw-search-profile": "Extended"

Thus everyone can adapt. "Extended" is fine with me too. The future will tell if there are other suggestions out there for the default naming. I do not expect any though.

@mwjames

This comment has been minimized.

Copy link
Contributor

mwjames commented Apr 22, 2018

@kghbln

This comment has been minimized.

Copy link
Member

kghbln commented Apr 22, 2018

Knock yourself out:

Thanks a lot for the kick-starting knock-out. 😄

@krabina

This comment has been minimized.

Copy link

krabina commented Apr 25, 2018

This is great!
I'd prefer "Structured" over "Extended", but more importantly I would like so see alle Namespaces hidden from the user unless I want to show them. Every SMW installation has tons of namespaces that just confuse the user. It's nice to have the option to see them and filter for them, but the default should be: don't show the namespaces to start with.
One solution could be to hide the checkboxes via css and allow them to be extended/displayed if the users wants to.
Even better would be a way to configure this. In cases with heavy use of custom namespaces having the possibility is great, but maybe I want to only show them the custom (content) namespaces e. g. "Book:", "Journal:", "Media:" but not the "built in" namespaces like "Form:", "Widget:", "Template", "Property"....

@kghbln

This comment has been minimized.

Copy link
Member

kghbln commented Apr 26, 2018

I'd prefer "Structured" over "Extended",

You will be able to adapt locally. See this #3126 (comment).

but more importantly I would like so see alle Namespaces hidden from the user unless I want to show them. ...

That's MediaWiki core and SMW cannot do anything to help here. I had the same issue on one wiki and our solution was to hide the namespace selection completely via CSS for good. This is however not the desired solution for most wikis. :|

Right now I cannot remember if I opened an issue on Phabricator or if I talked with one WMF employee about this referring to an existing issue on Phabricator. Currently I cannot point you to anything. I suggest to open an issue at Phabricator. The worst that can happen is that it gets duped to an existing issue. This however does not hurt since it tells people that there is interest in getting this improved. It will be cool if you could add me as CC to the task you created. Cheers and thanks!

@mwjames mwjames referenced this pull request Apr 28, 2018

Merged

Hide namespace section, auto-discovery, refs 3126 #3143

2 of 2 tasks complete
@mwjames

This comment has been minimized.

Copy link
Contributor

mwjames commented Apr 28, 2018

If I really have time I may make an discovery on the SEARCH_FORM_DEFINITION_RULE type but for the now all form definitions are expected to be hosted in Rule:Search-profile-form-definition.

See #3143.

I would like so see alle Namespaces hidden from the user unless I want to show them.

See #3143.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment