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

Category display format and sub-objects #1459

Closed
jcostello1 opened this Issue Mar 17, 2016 · 9 comments

Comments

Projects
None yet
3 participants
@jcostello1

jcostello1 commented Mar 17, 2016

I recently upgraded to SMW 2.3.1 and SRF 2.3 from a pre-2.2 version. I noticed today that the grouping behavior of the query output when format=category changed. Yes I've read the notes at https://www.semantic-mediawiki.org/wiki/Help:Category_format but the issue I'm seeing isn't covered.

I have a page that creates subobjects on people's burial information and I have other pages that list relevant names in a category format depending on the query parameters. Previously this worked well and the page grouped the results under the letter heading corresponding to the first letter of the surname property of the results. Since the upgrade, all results are grouped under a single letter heading, the one that corresponds to the first letter of the page title of the page that contains all of the subobjects.

My wiki isn't public so I can't provide a live example but an example of my query is:

{{#ask: [[Isgraverecord::+]] [[Era::1920s]]
|?Surname#
|?Givennames#
|?Init#
|mainlabel=-
|template=GravesListdisplaytemplate
|format=category
|sort=Surname,Init
}}

Is this an intentional change or a bug created during the rework of the Category format for the 2.2 release?

@mwjames

This comment has been minimized.

Contributor

mwjames commented Mar 17, 2016

Is this an intentional change or a bug created during the rework of the Category format for the 2.2 release?

I think #699 should be a good read with other discussions in #783, #1383, and #1010.

My wiki isn't public so I can't provide a live example

Feel free to use http://sandbox.semantic-mediawiki.org.

Related integration tests to category or category format include:

@kghbln @jaideraf It would be nice if someone could lead the investigation/discussion (I'm a bit preoccupied with multilingual stuff) on:

  • Whether we missed something or not
  • Whether this is a bug or feature, and if it is a bug then as to why and can it be reproduced
  • Example that demonstrates the issue clearly and can be modelled to be an integration test (so we don't have the same discussion in future)
@jcostello1

This comment has been minimized.

jcostello1 commented Mar 17, 2016

Thanks @mwjames for looking at this. I had read the discussions you mentioned but they are on sort order and not on the 'grouping'. Thinking about it now, perhaps the title I chose is misleading....

In my example, the results are sorted exactly as I would expect/desire them but the issue is they all appear under a single "letter" section on the category formatted page instead of the expected grouping by Surname.

I've requested a sandbox login (Jcostello1) so I can attempt to recreate the issue.

@jcostello1

This comment has been minimized.

jcostello1 commented Mar 17, 2016

Issue has been recreated in the sandbox.

Category-formatted results: http://sandbox.semantic-mediawiki.org/wiki/Gravesofthe1920s
Sourcedata: http://sandbox.semantic-mediawiki.org/wiki/Gravedataset

You'll see that all the results are sorted correctly by surname then initials (see Baker in list) but that they all appear in "G", the first letter of the Gravedataset pagename where the sub-objects are found. Desired/expected behavior would be for "A", "B", "G", "H", "J", "S" and "T" sections.

@jaideraf

This comment has been minimized.

Member

jaideraf commented Mar 19, 2016

Hi @jcostello1
You have to use |@sortkey={{{Surname|}}}, {{{Init}}} in your subobject declaration in the GraveSubObject template. See here for more details.

@jcostello1

This comment has been minimized.

jcostello1 commented Mar 19, 2016

Hi @jaideraf
Thanks for the pointer. How would the |@sortkey affect the subobjects when they're used in multiple ways? I use the same data for many queries and some have a different sort order. For example, on one page using a different output template I query all known burials and build a table sorted by Country, Region, Cemetery, Grave. Would the |@sortkey have any effect in those cases? Does it override the |sort parameter of the query itself?

As this worked without |@sortkey in pre-2.2 versions of SMW, do you know how/where the category-formatted pages produced the proper sorting before?

@mwjames

This comment has been minimized.

Contributor

mwjames commented Mar 19, 2016

Whether this is a bug or feature, and if it is a bug then as to why and can it be reproduced

It is a regression that has been introduced in 2.2 but since no one noticed it and we didn't have any test for it this scenario went unrecognized.

You have to use |@sortkey={{{Surname|}}}, {{{Init}}} in your subobject declaration in the

Works as well.

As this worked without |@sortkey in pre-2.2 versions of SMW, do you know how/where the category-formatted pages produced the proper sorting before?

I had a look at it #1461 and based on the examples, I tweak the printer to restore pre 2.2 behaviour for subobjects.

Now, https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/bug-1459/tests/phpunit/Integration/ByJsonScript/Fixtures/f-0303.json contains extra tests to cover the mentioned scenario (including sobj template setup, with/without sortkey, with explicit DEFAULSORT etc.).

@jcostello1

This comment has been minimized.

jcostello1 commented Mar 19, 2016

Fantastic @mwjames and much appreciated! This community never ceases to amaze me with it's level of support.

mwjames added a commit that referenced this issue Mar 19, 2016

Merge pull request #1461 from SemanticMediaWiki/bug-1459
Fix columnIndex in CategoryResultPrinter, refs #1459
@mwjames

This comment has been minimized.

Contributor

mwjames commented Mar 19, 2016

#1461 was merged and should be available by Sunday on the sandbox. Happy testing!

@jcostello1

This comment has been minimized.

jcostello1 commented Mar 20, 2016

Works perfectly! Thanks again @mwjames.

@jcostello1 jcostello1 closed this Mar 20, 2016

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