I'm new enough to this that I'm not sure my expectations count, but that
seems pretty good.
In theory there would be a version that mixes concerns a little but makes
the syntax a little simpler. Something like:
resourceHandler rh = resourceResolver,getHandler("/apps");
rh2 = rh.resource("1/2").resource("3/4"); // yields 1/2/3/4
rh2.resource("5/6"); // yields 1/2/3/4/5/6
rh2.resource("7/8"); // builds 1/2/3/4/7/8
I suspect this pattern would require multiple inheritance to avoid massive
refactoring so it's likely best left for the day you rewrite Sling in Scala
(you're going to do that right ? )
I'm running away now.....
Peter Hunsberger
On Mon, Dec 14, 2015 at 7:31 AM, Bertrand Delacretaz <[email protected]
> wrote:
> Hi,
>
> On Sat, Dec 12, 2015 at 5:47 PM, Peter Hunsberger
> <[email protected]> wrote:
> > ...I see. I had assumed a more functional style with the state travelling
> > with the return value, that then get's chained to the next call....
>
> I have modified the ResourceBuilder interface to work in this way, so
> you can now do
>
> final Resource r = resourceResolver.getResource("/apps");
> builderService.forParent(r).resource("1/2);
> builderService.forParent(r).resource("3/4");
>
> To create both /apps/1/2 and /apps/3/4.
>
> Basically you need to use either forResolver(ResourceResolver r) or
> forParent(Resource r) on the ResourceBuilder service to get a stateful
> ResourceBuilder, where you can then chain calls but not call the for*
> methods again.
>
> Is that closer to what you expected, or do you have a better idea?
>
> -Bertrand
>
