Filtering with modular contents

GaryHuangGaryHuang Member

Hello, I am new to kentico, and would like to ask a simple question.

For example, now I have 4 content types “Country”, “City”, “Contract”, and “Staff”



(1) “Country” has 2 items : “France”, “Japan”

(2) “City” has a modular content “Country”, 2 items :

  • “Paris” (modular content : “France”)
  • “Tokyo” (modular content : “Japan”)

(3) “Contract” has 2 items : “Full Time”, “Part Time”

(4) “Staff” has two modular content “City” and “Contract”, a few items like :

  • “Aaron” (modular content : “Paris”, “Full Time”)
  • “David” (modular content : “Paris”, “Part Time”)
  • “Katy” (modular content : “Tokyo”, “Full Time”)


I can only get the full list of “Staff” without filtering as below :
https://deliver.kenticocloud.com/PROJECT_ID/items?system.type=staff&depth=5&limit=5

But, How to filter the “Staff” list for “Full Time” staffs in “France” with the Delivery API ???

Answers

  • MichaelKinkaidMichaelKinkaid TorontoMember, MVP MVP

    Hey,

    The contract field is in the staff model so you can filter with that e.g.

    https://deliver.kenticocloud.com/PROJECT_ID/items?system.type=staff&elements.contract[contains]=full_time

    Country isn't directly in the staff model however. City is, and the hope is that you can use that relationship to filter. I couldn't work out how to do this either, so hopefully we either get confirmation that is isn't possible with the current model setup, or someone shares their smarts :-).

    Some options to consider:

    Option 1
    The call we can do will return all the information you need to evaluate it on the client side (see the modular content object in the JSON after the items array). That links cities to countries. You'd have to ask the API for all staff who are full time and then once you had that data filter on the client side.

    Option 2
    Assuming the relationship between city and country wasn't something that needed maintained, and it isn't a big ask to get editors to set city and country at the staff level then I'd opt for using a city taxonomy and a country taxonomy (use taxonomy so you can manage the lists). You can then filter by either:

    https://deliver.kenticocloud.com/PROJECT_ID/items?system.type=staff&elements.contract[contains]=full_time&elements.country[contains]=france

    Cheers,
    Michael

  • petrs@kentico.com[email protected] Eindhoven, NLMember, Administrator, Kentico Staff admin
    edited June 2017

    @MichaelKinkaid sure you can use the relationship to filter the content. Just use any of the array filtering operators.

    For example:
    https://deliver.kenticocloud.com//items?system.type=staff&elements.city[contains]=london

  • MichaelKinkaidMichaelKinkaid TorontoMember, MVP MVP

    @petrsvihlik - what about in the scenario @GaryHuang presented where he wants to filter Staff by Country but Country is not a field in the Staff Content Type. Rather City is a field, and he wants to use the fact that City, which is referenced in Staff, is related to a Country.

    As presented in my answer, I don't think this is possible from an API call given the model that is presented. The relationship from City to Country can be determined from the modular content JSON (after the items array) on a call to get a Staff item, but the API only supports filtering a content type (in this case Staff) by the system and element values within that Content Type, and not by a deeper relationship e.g. Staff > City > Country.

    Filtering in that way (filtering Staff by County by way of City) would require work done on the client side using the modular content information provided after the items array - or an update to the model, say adding both City and Country fields to Staff.

  • petrs@kentico.com[email protected] Eindhoven, NLMember, Administrator, Kentico Staff admin

    Yes, that's correct. Currently, you can't filter based on nested item's elements.
    The solution is, indeed, to set the depth parameter to an appropriate value, retrieve the data all at once and filter it in memory.

    @TomasHruby Any plans on extending the query language in this direction?

  • TomasH@kentico.com[email protected] Member, Kentico Staff mod

    This is a fascinating discussion, thanks for including me, @petrsvihlik. Building more complex query language (such as graphQL) is in our long-term vision, but not in the short term future. It's all about what customer feedback we get and currently, we believe that other features on our roadmap are going to improve Kentico Cloud experience more significantly. However, I'll keep an eye on it, because it's interesting for me, personally. Let me add your feedback to similar suggestions. At the moment, as @MichaelKinkaid mentioned, you can either filter the client on the client or denormalize the schema and include the country in staff.

    @GaryHuang, Michael suggested correctly, that you can use taxonomy instead of content items. This leads me to the questions, what data you need to manage for countries, cities, and contract. Is there other content than e.g. the name of the city and relationship to the country? If yes, please can you share with us the whole model? I believe it will help us understand the use-case when designing API improvements. Thanks.

  • MichaelKinkaidMichaelKinkaid TorontoMember, MVP MVP

    @TomasHruby - loving the idea of GraphQL. I've been checking it out on other platforms and it looks really intuitive.

  • mabrahams675mabrahams675 Sydney, AustraliaMember

    From my experience the "best" way to handle this is to maintain a search index. So for your example you'd want to have an index for staff which would include the values of your nested modular items (FirstName, LastName, Country, City, Contract).

    So instead of querying the Delivery API in your client application you would query your search index. If you are creating a listing view, you would want to store all of the additional staff properties in the search document that are required by the view to avoid additional calls to the Delivery API. If you can stick to that it will perform and scale extremely well (1 query to the search index per page).

    This approach is a bit of work to set up (webhook endpoint, search index etc), but it's a pattern that you can use on every project, this scenario will come up time and time again.

    The quick and fast way as mentioned by someone else is to pull all staff via the Delivery API and filter the results in memory. This approach will not scale but is fine for small datasets.

  • JanL@kentico.com[email protected] Czech RepublicMember, Administrator, Kentico Staff admin

    Hi @mabrahams675 , nice point with the search index workaround. In the long term, I'm a fan of GraphQL, but, for the time being, flattening the structure to an index would certainly work a treat.

    Perhaps, if you'd like to share some code example, so that the rest of the community would get the grips quickly, that would be awesome.

Sign In or Register to comment.