Well,think of that templating example. To make the Twig `path` function
work the template engine needs to be integrated with the router. Having an
interface for that would make template engines easier to integrate.
On Tuesday, January 3, 2017 at 12:39:48 AM UTC+1, Hannah Warmbier wrote:
>
> If by 'route parameters' you mean params that are injected into or used by
> a controller, this is not simple URL building and, IMO, should not be the
> concern of a router.
>
> I'm not sure how FIG could standardize this. Routing? Sure. URL building
> (e.g. RFC 6570 to PSR-7 Uri)? Sure. But I think you're venturing into a
> part of libraries/frameworks that is specific/unique to each, and doesn't
> make sense to standardize.
>
> On Sunday, January 1, 2017 at 8:17:32 PM UTC-6, Dracony wrote:
>>
>> Well you still need to call such a function something, right? Also not
>> all route parameters necessarily map directly 1:1 to url parameters. So I
>> think a more general solution is better.
>>
>> Also simply returning a url template would require client libraries to
>> also do the substitutions instead of just getting a ready made url.
>>
>> On 2 Jan 2017 01:12, "Woody Gilk" <woody...@gmail.com> wrote:
>>
>>> Hannah,
>>>
>>> Thanks for sharing that, it looks super useful for a number of
>>> situations!
>>>
>>>
>>> Roman,
>>>
>>> All you would need to use RFC 6570 is a function/method that returns a
>>> route "template" from a name:
>>>
>>>
>>> function routeUrl($name, array $params)
>>> {
>>> $template = function_to_get_route_template($name);
>>> return rfc6570_expand($template, $params);
>>> }
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Woody Gilk
>>> http://about.me/shadowhand
>>>
>>> On Sun, Jan 1, 2017 at 1:35 PM, Roman Tsiupa <draco...@gmail.com> wrote:
>>>
>>>> Still not what I had in mind. A templating engine that is generating
>>>> links on your page should really have no idea of the actual URL structure,
>>>> just a route name.
>>>>
>>>> E.g. when you do in twig:
>>>>
>>>>
>>>>
>>>> <a href="{{ path('article_show', {'slug': article.slug}) }}">
>>>> {{ article.title }}
>>>> </a>
>>>>
>>>>
>>>> On 1 Jan 2017 19:59, "Hannah Warmbier" <hannah....@gmail.com> wrote:
>>>>
>>>>> Not sure if this is what you're looking for either, but are you aware
>>>>> of RFC 6570?
>>>>>
>>>>> https://tools.ietf.org/html/rfc6570
>>>>>
>>>>> There are a number of PHP libraries that implement it.
>>>>>
>>>>> On Friday, December 30, 2016 at 1:42:16 PM UTC-6, Dracony wrote:
>>>>>>
>>>>>> Thats not what I had in mind.
>>>>>> I was thinking about something like this:
>>>>>>
>>>>>>
>>>>>> http://api.symfony.com/2.3/Symfony/Component/Routing/Generator/UrlGenerator.html#method_generate
>>>>>>
>>>>>> Not evolving the url, but generating a URL from a route name and and
>>>>>> array of parameters.
>>>>>>
>>>>>> On 30 Dec 2016 20:38, "Larry Garfield" <la...@garfieldtech.com>
>>>>>> wrote:
>>>>>>
>>>>>>> On 12/30/2016 11:05 AM, Dracony wrote:
>>>>>>>
>>>>>>>> So I read through the Routing PSR idea and honestly I can't think
>>>>>>>> of it having too many use cases. Why would you ever need to replace a
>>>>>>>> whole
>>>>>>>> router really? But that got me thinking about a different, and much
>>>>>>>> more
>>>>>>>> useful usecase.
>>>>>>>>
>>>>>>>> While matching the URL to some parameters is usually done once and
>>>>>>>> by the framework itself usually what happens a lot is URL generation
>>>>>>>> within
>>>>>>>> the app. So instead of a full blown routing PSR I propose a simpler
>>>>>>>> one
>>>>>>>> which just provides interfaces for generating URLs from an array of
>>>>>>>> parameters. This would be much more useful immediately since these URL
>>>>>>>> generators could be passed to template renderers to build links, which
>>>>>>>> would make integration of these engines within frameworks easier. This
>>>>>>>> would also mean that some payment processing libraries would be easier
>>>>>>>> to
>>>>>>>> use since they would be able to automatically generate URLs to
>>>>>>>> appropriate
>>>>>>>> controllers etc.
>>>>>>>>
>>>>>>>
>>>>>>> PSR-7 already defines an evolvable Uri object:
>>>>>>>
>>>>>>> http://www.php-fig.org/psr/psr-7/#3-5-psr-http-message-uriinterface
>>>>>>>
>>>>>>> That seems sufficient for most use cases.
>>>>>>>
>>>>>>> --Larry Garfield
>>>>>>>
>>>>>>> --
>>>>>>> You received this message because you are subscribed to a topic in
>>>>>>> the Google Groups "PHP Framework Interoperability Group" group.
>>>>>>> To unsubscribe from this topic, visit
>>>>>>> https://groups.google.com/d/topic/php-fig/q2T5hJQQhwk/unsubscribe.
>>>>>>> To unsubscribe from this group and all its topics, send an email to
>>>>>>> php-fig+u...@googlegroups.com.
>>>>>>> To post to this group, send email to php...@googlegroups.com.
>>>>>>> To view this discussion on the web visit
>>>>>>> https://groups.google.com/d/msgid/php-fig/7a248957-75ef-b44d-5434-e87e73607d8f%40garfieldtech.com
>>>>>>> .
>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>
>>>>>>> --
>>>>> You received this message because you are subscribed to a topic in the
>>>>> Google Groups "PHP Framework Interoperability Group" group.
>>>>> To unsubscribe from this topic, visit
>>>>> https://groups.google.com/d/topic/php-fig/q2T5hJQQhwk/unsubscribe.
>>>>> To unsubscribe from this group and all its topics, send an email to
>>>>> php-fig+u...@googlegroups.com.
>>>>> To post to this group, send email to php...@googlegroups.com.
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/d/msgid/php-fig/5cfca8fd-6a90-41aa-90bf-51b1203dfad0%40googlegroups.com
>>>>>
>>>>> <https://groups.google.com/d/msgid/php-fig/5cfca8fd-6a90-41aa-90bf-51b1203dfad0%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "PHP Framework Interoperability Group" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to php-fig+u...@googlegroups.com.
>>>> To post to this group, send email to php...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/php-fig/CANamvv2bLRjEGZd2wywkXQGyzGSNjzP343euy3bMtpywmvzOYQ%40mail.gmail.com
>>>>
>>>> <https://groups.google.com/d/msgid/php-fig/CANamvv2bLRjEGZd2wywkXQGyzGSNjzP343euy3bMtpywmvzOYQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "PHP Framework Interoperability Group" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/php-fig/q2T5hJQQhwk/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> php-fig+u...@googlegroups.com.
>>> To post to this group, send email to php...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/php-fig/CAGOJM6K9qiXrahLt41Ym%2BS_f6aVM-L8tRZ7aP8isPqhwE5enug%40mail.gmail.com
>>>
>>> <https://groups.google.com/d/msgid/php-fig/CAGOJM6K9qiXrahLt41Ym%2BS_f6aVM-L8tRZ7aP8isPqhwE5enug%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
--
You received this message because you are subscribed to the Google Groups "PHP
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/9f88844e-d928-4bd9-ba5c-6aa77611224e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
