Allow usage of Pages in URL Suffix Builder

Description

Currently it's only possible to use Resources for the Suffix creation:

As soon as you want to build a suffix for two page-resources, this fails as the resources are no descendents.

java.lang.IllegalArgumentException: the resource JcrNodeResource, type=/apps/foo/components/page/bar, superType=null, path=/content/foo/bar/ipsum/jcr:content is not a descendent of the base resource JcrNodeResource, type=/apps/foo/components/page/bar, superType=null, path=/content/foo/bar/jcr:content

Activity

Show:
Alexander Muthmann
March 31, 2016, 8:38 PM
Edited

https://github.com/wcm-io/wcm-io-handler/pull/3

Notes:

  • The naming of the Test-Methods is a little bit strange (e.g. testGetLongIntBooleanStringResourceFilterOfResourceString). Not sure if this is intentional, I just reused them to ensure a consistent naming.

  • To avoid bloating up the SuffixParser, I didn't overload all getPages(...) methods, only the getPage(...) ones.

Stefan Seifert
April 12, 2016, 1:14 AM

i think it would make more sense to use Filter<Page> instead of Filter<Resource> for the SuffixParser.getPage/getPages methods with filtering?

Alexander Muthmann
April 12, 2016, 4:13 PM

But then it would not be possible to reuse the "getResourcesWithBaseResource" method. I thought about this too, but as there are not many (if any?) filter options for pages that do not exist for resources, I decided against it.

Stefan Seifert
April 12, 2016, 8:43 PM

it is more consistent to use Filter<Page> instead of Filter<Resource>, and it's easy to still reuse getResourcesWithBaseResource.

i've enhanced your patch to reflect this and added some more signature missing compared to the signature variants for resources.

merged in rev. 441dfb1592cb1f35ad153634b91b35483ec3c475 and now available in the current snapshot.

Alexander Muthmann
April 12, 2016, 8:47 PM

thx

Fixed

Assignee

Alexander Muthmann

Reporter

Alexander Muthmann

Labels

None

Components

Fix versions

Priority

Major