fix all those "Alias" issues

[ikkez]

I noticed that the topic about alias routes wasn't completly fine yet.
I had a look at #692, #693 and #712 and also saw multiple threads at the board, complaining about a missing feature when it goes about replacing the tokens in the url:
https://groups.google.com/forum/#!searchin/f3-framework/alias/f3-framework/cctEWVHNBVo/3RD0XvaJG_kJ
https://groups.google.com/forum/#!searchin/f3-framework/alias/f3-framework/xUrMhuZlXDo/esHedT2tD6sJ
https://groups.google.com/forum/#!searchin/f3-framework/alias/f3-framework/uQhZZKoc-vI/7i6TNKJn-p8J

so here is a proposal.

1. keep the alias name of the current route in a hive var. (ALIAS)
2. use that current alias name, to fetch the route url from the ALIASES hive array
3. added a method to assemble the URL based on a given alias name.

here is how it looks now:

$f3->route('GET @foo: /alias-test/@a/@b', function () {
    echo \Template::instance()->render('test.html');
});

<a href="{{@ALIASES.foo}}">old way, still works. auto-populates @a and @b</a>
<a href="{{ \Base::instance()->alias('foo','@a=123,@b=germany') }}">
the long new method way, that let you change all tokens
</a>
<a href="{{ 'foo', '@a=456,@b=foo' | alias }}">convenience token filter method</a>

There would be other ways to solve it too, and maybe have it a bit nicer, like @ALIASES.foo(@a=789) but i don't wanted to create another plugin for that (with magic __get or __call methods) and wanted it to be fully backward compatible.

It would have been nice to have a move generic url parser like {{@ALIASES.foo,'@a=456,@b=foo'|alias}} but this doesn't work completely, because the main problem is that this line https://github.com/bcosca/fatfree/blob/dev/lib/base.php#L2227 is nice for having pre-filled alias routes, but also takes the chance of changing the tokens to something else afterwards, because they would already be replaced if your current route contains parameters that are also used in the alias route. It all would probably be nicer if it wouldn't do it here, but to keep compatibility, i did a workaround with a copy of $this->hive['ALIASES'] that is still untouched, and backup the PARAMS, since the parse method would overwrite them and cause weird behaviours if your app continues after rendering some urls.

so what do you think?

[sgpinkus]

I would change Base::build() to take an optional $params parameters, rather than clobbering a hive var and then restoring it. It's cleaner.

Also one issue that may arise here is an error handler relying on the hive which has not been restored?

[ikkez]

That would'nt make a difference, because the parse function is the one that overwrites the PARAMS hive key.
Although the $url argument expects an URL - still need a place to do $url = $this->hive['ALIASES'][$name] somewhere.
But if we touch the parse method, to return an array instead of pushing it to PARAMS and use that array in build, that could be working a bit nicer, but introduces more changes.

[ikkez]

okay, i changed some parts now to drop the need of backing up the PARAMS key.
As suggested, build has now an additional $params argument.

[xfra35]

👍 for those changes, they are much needed

I also agree with the change introduced in the parse() and build() functions, which make code cleaner.

[ikkez]

alright, should be fine now. give it a try.

[xfra35]

Yeah it works 👍
also with variables: {{ @name, 'a=5,b='.@id | alias }}
or with the current route: {{ @ALIAS, 'a=5,b='.@id | alias }}

So here's a summary of the new features:

echo $f3->alias('foo','a=5,b=2');//=> /alias-test/5/2
echo $tpl->resolve("{{ 'foo', 'a=5,b=2' | alias }}");//=> /alias-test/5/2
print_r($f3->parse('a=5,b=2'));//=> Array ( [a] => 5 [b] => 2 )

[KOTRET]

nice 👍

[HwapX]

do not forget the * wildcard it must be removed or the result should be a way to set its value.