This almost works, see the question above about prefixes.

i have problems seeing how this is different from the phpcr router. i thought you check puli for a file and provide a route to download that file. but this is doing something else. i don't know enough of puli to exactly understand what the point of this is. can you explain that a bit please?

does this belong into this repo or into one of the resource repositories?

The way this is configured at the moment, it is functionaly equivilent to the PHPCR-ODM router as we have configured the PhpcrRepository directly.

However, it becomes more interesting when you use a more fancy repository, such as a "context aware" repository which would change the repositories base path depending on the host (multi-portal/site).

Or if you use a composite repository to combine several different route sources into a single tree.

Or you could use a cascading repository try a sequence of repositories, for example first try Site A, then Site B then fallback to Default Site.

@webmozart BTW what is the ETA for a stable Puli release?

@lsmith77 March 2015. I want to publish a RC in February.

@dantleech now that puli is released, any chance that you wrap this up?

and does this still belong here or rather into the ResourceBundle?

I think this would depend on a release of the Resource lib. and bundle
so I think effort should go there first.

I am currently dedicating nearly all of my resources to another project
so don't have time to get back into Resource stuff atm, but maybe late
next month.

With respect to where this belongs, it probably doesn't belong here, at
least while the Resource stuff is still experimental. Is it in the scope
fo this bundle to provide third-party route providers?

On Fri, Aug 21, 2015 at 05:03:55AM -0700, David Buchmann wrote:

and does this still belong here or rather into the ResourceBundle?

—
Reply to this email directly or [1]view it on GitHub.

Reverse link: [2]unknown

References

Visible links

1. CMF Resource provider #288 (comment)
2. CMF Resource provider #288 (comment)

actually i feel the ResourceBundle would be the more natural fit for this. its all about resources. but of course in most real-world scenarios, one would want to use this provider with the CmfRoutingBundle to hook the provider into the dynamic router for example.

i removed the milestone. if you agree, move the code to ResourceBundle and close this.

As I am moving the code now I see why I put it here in the first place.
The RoutingBundle already natively supports both the Doctrine ORM and
PHPCR-ODM route providers. Why shouldn't it, in theory, also support the
CMF/Puli resources?

On Fri, Aug 21, 2015 at 06:17:16AM -0700, David Buchmann wrote:

i removed the milestone. if you agree, move the code to ResourceBundle and
close this.

—
Reply to this email directly or [1]view it on GitHub.

Reverse link: [2]unknown

References

Visible links

1. CMF Resource provider #288 (comment)
2. CMF Resource provider #288 (comment)

I actually believe in the future, the resource provider might take over both other route providers. Resource can handle PHPCR, ORM, filesystem, etc. natively.

Rebased -- but merging would depend on a stable release of the Resource stuff and also I or somebody would have to invest time in this as it is probably non trivial.

Hmm, I'm not sure if I really like the way this PR works. Basically, this PR lets you configure a repository for the routing stuff. This means we are limited to one repository and the RoutingBundle config is aware of the backend type (as that's the repository).

I'm more thinking about only 1 repository per application: The default repository. This can then be configured by the CmfResourceBundle. This allows you to, for instance, bind multiple different backends to the default Composite repository.

Using the Puli Discovery component, the RoutingBundle can then find all routes:

class ResourcesRouteProvider // ...
{
    // ...

    public function getRouteCollectionForRequest(Request $request)
    {
        $path = $request->getPathInfo();

        foreach ($this->getPaths($path) as $targetPath) {
            $this->findRoutes($targetPath, $collection);
        }
    }

    private function findRoutes($path, $collection)
    {
        $bindings = $this->discovery->findByPathAndType($path, 'cmf/routes');

        foreach ($bindings as $binding) {
            foreach ($binding->getResources() as $resource) {
                // ...
            }
        }
    }
}

Configuration then looks like:

cmf_resource:
    repositories:
        routing_phpcr:
            type: doctrine_phpcr_odm
            basepath: /cmf/routing

        default:
            type: composite
            mounts:
                - { repository: routing_phpcr, mountpoint: /phpcr/routes }
    bindings:
        - { path: /phpcr/routes, type: cmf/routes }

cmf_routing:
    persistence:
        resource:
            repository: default

Could we not just have it default to default and keep the option to use an alternative repository?

Yeah, we should still allow other repository names as well. However, I think tagging is really the implementation we need here, as it allows to have routes in multiple locations. E.g. simple cms documents and routes.

Not sure what you mean by "tagging"?

Sorry, type binding. As shown in my comment above, using Puli Discovery.

ok yeah, so you would configure whatever repositories in the ResourceBundle, "bind" them to a Puli type and then let the Discovery component handle the rest in the RoutingProvider, sounds like the best way to do it.

In case this is relevant here: the Discovery component will be extended in beta8. Binding types will become actual PHP interface (or class) names such as Cmf\Resource\ResourceBundle. You'll be able to annotate this interface:

/**
 * @BindingType
 * @Subject("RESOURCE")
 */
interface ResourceBundle {}

or continue to mark it as binding type with the CLI:

$ puli type --register Cmf\\Resource\\ResourceBundle

Furthermore and most important, it will be possible to bind class names:

/**
 * @BindingType
 * @Subject("CLASS")
 */
interface Service {}

$ puli bind My\\ConcreteService Cmf\\Api\\Service

This could be useful here.

Especially that second feature would be usefull :) (I assume the code of puli bind will be available as a normal PHP method that we can use in the ResourceBundle?)

@wouterj of course, same as now :)

See puli/issues#114 for more detail

@wouterj @dantleech is this a blocker for the 2.0 bundle? i guess we can't really do it in a BC way so if its not in 2.0 it will have to wait for quite a while. but i really want to get 2.0 moving to get symfony 3 support.

@dbu I see this as a feature, not a BC break. We would just be adding a new Provider .. ? In which case we can release 2.0 and put this in 2.1 if it turns out to be a worthy addition.

This should be closed in favor of #314 btw

oh, didn't see that one :) well done.