Closed sstok closed 6 years ago
Instead of making this to feature envy, it's possible to add support for {_locale}
and host requirements without to much effort.
OK, the good news is. It possible, for host at least. And I actually managed to do this 👍
Using icomefromthenet/reverse-regex
you can create results based on a regex and then check if these outcomes match the other patterns, making host groups instead of checking hosts statically.
Adding this for the prefix is going to kill me 💀 The amount of possible outcomes is to complex for what anyone would ever use, eg. you have to require anyone who uses placeholders to provide a regex that doesn't conflict with others (defeating the purpose of this bundle) or you can't use complex expressions.
Instead for the prefix I'm thinking of a |
to allow more then one static prefix, these can still be validated and allow for more complex prefixes like backend|admin|bop
.
I have an idea how to solve this, but it's going to be big BC break.
Basically the following: Remove support regex in host and prefix, it's still possible to use multiple values (admin|backoffice
) but no advanced regexp.
This makes the configuration more predictable and makes adding features much easier.
Resolved by #18
To add support for placeholders there a number of risks. A negative lookahead regex pattern must only be used when there are sections that match, else
^/(?!(user)/)
is going to fail with/user/
in the backend section (with it's host).Regex parsing is a complex and error prone process, and needs to as good as possible. This however means that complex patterns are not supported, only simple ones with a single-level grouping (
en_(us|uk)
,(en|nl)
) and no look around placeholders replaces ((something)_\1
).Some idea's and notes for later: