Some questions

[attiks]

Is any of the following available out of the box and if not is it possible to code it

• [ ] OR Filter on multiple values like ?filter[tag]=1,2
• [x] AND Filter on multiple values like ?filter[tag]=1+2
• [x] Add a custom end point like news_articles that prefilters on articles tagged with news, but allows extra filters as well
• [x] Related entities, similar like tags but generated by code
• [ ] Can some filters be disabled
• [x] Is there support for pagination, so the client can specify the page number and the number of results per page (with an upper limit)?
• [x] In case paging is supported, is the total number of pages returned as well? Or is the count the total number of items? This is needed so the client can render a pager.

[e0ipso]

Can some filters be disabled

You can have all filters exposed to the URL or all filters disabled. This is per resource basis.

OR Filter on multiple values like ?filter[tag]=1,2

Right now, all conjunctions are considered ANDs.

Everything else is supported.

In case paging is supported, is the total number of pages returned as well?

You have the total number of items to build a pager and hypermedia links to previous and next pages.

If you consider using this module after all I would be very glad if you wrote some kind of success case / module review / etc

[attiks]

Thanks for the prompt response

• Can I expose a resource with custom filters?
• I assume I can add support for OR filters in code?

If we choose to use this (read if it is fast enough) I'll do a write up.

PS: Do you know if somebody already added support for commerce products?

[e0ipso]

You can do pretty much anything in code. You just need to override the necessary methods in your resource class, which are really simple. This is a big deal for us. You get everything out of the box, but we let you override every small piece to meet even the craziest use case.

Can I expose a resource with custom filters?

Sure, just declare your default filters.

I assume I can add support for OR filters in code?

You can override the method getQueryForListFilter iirc and add support for OR in there, although I would much rather if you submitted a PR for that :wink:

read if it is fast enough

You have a fine grain control over render caching. Additionally this module supports reverse proxy caching. See this for a naive / initial performance comparison.

[amitaibu]

Hi @attiks

PS: Do you know if somebody already added support for commerce products?

If you look at the example files - you will see adding support for commerce products is going to be pretty easy, as you just need to implement publidFieldsInfo.

[attiks]

I did some more testing, but I could not find how to properly add support for entity translation, looking at the article example:

• nl/api/v1.5/articles/5013 returns the nl body and nl title
• fr/api/v1.5/articles/5013 returns the NL body and the fr title

I guess it returns the nl body, because that is the original language

Using nl/api/v1.7/articles/5013, fr/api/v1.7/articles/5013 returns the right value, but I guess this is because it returns the rendered value (which I don't really need)

[amitaibu]

@attiks @mateu-aguilo-bosch we should probably be language aware which we currently are not. Question is thought if we shouldn't opt for outputting all the languages under a single field so api/articles should return

body: {
  fr: 'Bonjour'
  en: 'Hello'
}

(Which I like better)

[attiks]

@amitaibu not sure if outputting all the languages by default is the best way, but maybe it might be a config option, I think outputting all languages can already be done in code by tweaking the publicFieldsInfo.

If a site has lots of languages and the client only need to use one at the time, it might be easier to just output the one language, if it is outputted as body, that also implies that translating the front end is way easier sine you can use the same calls, but with a different language prefix.

We'll have an in depth look tomorrow at the code, I'll add this to our list.

[attiks]

@amitaibu strange thing is that it works for the title (using the title module)

[e0ipso]

Question is thought if we shouldn't opt for outputting all the languages under a single field

I would much rather output a single language, and let core's language negotiation strategies decide which language to use. Imagine a site with four languages + several long text fields + listing 50 items. You could be creating an HTTP transfer performance bottleneck.

I'm not sure why EMW is not picking the negotiated value in this case, but I think this is a bug.

[attiks]

@Jelle-S is building a POC to make sure we can do whatever we want, first PR is already submitted

[e0ipso]

Closed in an issue purge. Please, feel free to reopen if necessary.