[Feature Request] Make it possible to load objects from specific hierarchy level

[julkue]

When building a Product Listing Page we want to show items of the first hierachy level, which is the color variant in our case. Further nested levels like size etc. should not be displayed on the listing page, only on the detail page.

With our own PR #150 we've introduced the possibility to get children, so we could theoretically call something like a getProductListing, then directly go on the first variant hierarchy level and get all the information we need.

But this can not be a solution since it would not be possible to get a totalCount for this specific level nor would it work with paginations, where it should be possible to load only the first "X" elements and with an offset like specified in the docs. Since it would not be relative to the specific variant level, but to the entire product listing.

The current solution would probably be to build a custom query, but then it'd be necessary to re-build default things like

    defaultLanguage: $lang,
    sortOrder: "ASC",
    published: true,
    first: $limit,
    after: $offset

Or am I missing something?

Please take this as a Feature Request to load hierarchy specific objects.

[juckerf]

probably it would help to have POST_BUILD event instead of just a PRE_BUILD (to extend behaviour of core types, resolvers etc.) or to have some way to inject some advanced custom filter logic in the "*Listing"-Endpoints (the current filter only allows to filter based on fields of the objects database table)

[juckerf]

something like the legacy condition logic for webservices (https://pimcore.com/docs/6.x/Development_Documentation/Web_Services/Query_Filters.html#page_Legacy-Mode), just for data-hub, would allow one to add any custom filter logic to a query. what do you think about it @weisswurstkanone ?

[weisswurstkanone]

well, the code is already there and used for normal listings. see https://github.com/pimcore/data-hub/blob/1a640d6574efc82708aeee69f0cedcd1fc353888/src/GraphQL/Helper.php#L19

[juckerf]

If my understanding is correct this only allows very limited filter possibilities (based on simple equals, Like, gt, lt "where"-conditions on columns of the objects table).-- Sent from my Android phone with GMX Mail. Please excuse my brevity.On 28/04/2020, 09:25 Josef Aichhorn notifications@github.com wrote:

well, the code is already there and used for normal listings. see https://github.com/pimcore/data-hub/blob/1a640d6574efc82708aeee69f0cedcd1fc353888/src/GraphQL/Helper.php#L19 —You are receiving this because you commented.Reply to this email directly, view it on GitHub, or unsubscribe.

[weisswurstkanone]

Sounds like a very special use case, maybe it is better to use a custom endpoint which gives you the full flexibility.

see https://github.com/pimcore/data-hub/blob/master/doc/graphl/AddCustomQuery.md

[julkue]

@weisswurstkanone Yes, but then we'd have to re-implement all of the Pimcore standard functionality like mentioned in my initial post. And we'd like to avoid that. If there would be a simple way to hook into DataHubs response that allows to filter for the hierarchy level like we need it here, this would be a much cleaner way and scalable.

[juckerf]

I agree that the use case is very specific. That's why I try to come up with a generic solution which probably would be beneficial to all pimcore users.A custom query as proposed would be one solution for our use case but as @julmot mentioned this means we have to copy&paste a lot of existing data-hub code.-- Sent from my Android phone with GMX Mail. Please excuse my brevity.On 28/04/2020, 11:36 Josef Aichhorn notifications@github.com wrote:

Sounds like a very special use case, maybe it is better to use a custom endpoint which gives you the full flexibility. see https://github.com/pimcore/data-hub/blob/master/doc/graphl/AddCustomQuery.md —You are receiving this because you commented.Reply to this email directly, view it on GitHub, or unsubscribe.

[weisswurstkanone]

Can you provide a PoC that works for you ?

[juckerf]

before getting into PoC implementations I'd like to discuss possible solutions. The one I came up now would provide a new event to hook into the listing resolver somewhere before the list is actually loaded (https://github.com/pimcore/data-hub/blob/master/src/GraphQL/Resolver/QueryType.php#L395). An example would look like this:

\Pimcore::getEventDispatcher()->addListener(\Pimcore\Bundle\DataHubBundle\Event\GraphQL\ListingEvents::PRE_LOAD,
    function (\Pimcore\Bundle\DataHubBundle\Event\GraphQL\Model\ListingEvent $event) {
        $listing = $event->getListing();
        $args = $event->getArgs();

        if ($args['onlyShowFirstLevelVariants']) {
          $listing->setCondition('(o_parentId IN (SELECT o_id FROM objects WHERE o_type=\'object\') AND o_type = \'variant\')');
        }

        $event->setListing($listing);
    });

The event has access to the listing object and the arguments array (other parameters have to be discussed).

If you're okay with something like this I'm happy to provide a POC implementation

[weisswurstkanone]

I would say an additional event doesn't hurt. What do others think ?

BTW, do we have a section in the documentation about available events ?

[juckerf]

I implemented a POC implementation, see PR #213 And yes, there's already a documentation section about events: https://github.com/pimcore/data-hub/blob/master/doc/graphl/Events.md

Another thing I'd like to discuss in this context: how about adding a POST_BUILD MutationType/QueryTypeEvent called at the end of the schema build (e.g. https://github.com/pimcore/data-hub/blob/4bc63245e78ceffe41f31530530f342814c2b458/src/GraphQL/Query/QueryType.php#L303)? This would allow much more control over extending the schema with custom arguments etc. This would be useful too in the use case of this issue, but not absolutely necessary since there are other, more complicated ways to achieve a similar behaviour which works for us.

[julkue]

Closed as per our contribution in #216. Thanks to @juckerf