Consider Refactoring and Extracting PathResolver and URLResolver

Currently, PathResolver and URLResolver are used as strategies, and their corresponding facades live in the core package. It would be nice to create separate path and url packages for these interfaces and their corresponding facades so that these can be used without depending on the template repository as there are other cases for these packages that doesn't necessarily involve rendering templates.

The more immediate concern is that there's usually more than one root path that needs to be considered for a package. In Siren, for example, there are extensions that are built into the plugin and sometimes they have their own scripts that need to be rendered, but those scripts are inside of the extension, which is built to be able to run as its own package or within Siren itself.

The consequence of this is that we cannot use either resolver in the intended way because each of these are associated with the generic root of the entire project, not the root of individual packages.

It would be worth exploring potential patterns that we can use to make it possible to have multiple paths/URLs that can be called upon.

It's also entirely possible that the solution is to establish a more-robust pattern inside the DI container that allows us to conditionally resolve an abstract based on certain parameters. Doing so would allow us to have multiple strategies for a single interface and allow us to conditionally use the right one in the correct circumstance.

It could also be that we need to add a registry in the core or framework package that allows us to register different registries, but that seems like a lateral transition since we're just moving where we store our constants.

phpnomad / template

Consider Refactoring and Extracting PathResolver and URLResolver #1