Documentation packages refactoring

[everzet]

This PR is a direct answer to the discussion in #7.

It separates notions of package and repository into separate domain concepts and basically builds thing discussed in https://github.com/everzet/Borg/issues/7#issuecomment-68584368 on top of it.

This should essentially fix issues 1, 4 and 5 of #7 and enable easy resolution of 2 and 3, which will come with a separate PR.

[stof]

I will review this PR this evening

[everzet]

:+1: thanks

[stof]

I see an issue currently: the package name validation in the domain and the package name requirement in routes are not consistent (the routing is stricter by allowing only some chars in the names). And the routing requirements are not compatible with Composer package names (which are allowing dots as well)

[everzet]

I see an issue currently: the package name validation in the domain and the package name requirement in routes are not consistent (the routing is stricter by allowing only some chars in the names). And the routing requirements are not compatible with Composer package names (which are allowing dots as well)

I think we can actually make route requirements much more liberating now. Lets just make sure there are no security tricks allowed, other than that - trying to get wrong documentation should just result us in being unable to find that documentation.

[everzet]

@stof "more liberating" = [^\/]++\/[^\/]++

[stof]

IMO, this will create other issues. If someone names its package v3.0/foo.html, it might create an issue for the foo.html page of the behat doc because of the URL patterns

[everzet]

@stof such a package will not get into the system because of the name constraints in *Package VOs.

[stof]

@everzet this is a valid composer package name

[everzet]

oh wait. No it will. v3.0/foo.html is a valid package name, is it :D

[everzet]

that's a very-very good point. Should we mount extensions documentation under different prefix (/extensions)? That should sort it out.

[stof]

anyway, let's discuss the URL patterns separately. They are not part of this domain refactoring. But yes, I think a prefix might help

[everzet]

@stof opened separate issue for that. Ok back to this refactoring. What else?

[everzet]

@stof anything else?

[stof]

:+1:

[everzet]

@stof next is support for develop, master and v2.0.x documentation versions :)

[stof]

I have an idea for a small improvement making it easier to handle consistent routing requirements. I will send it before this refactoring.