Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add url_alias property to Location #91

Closed
iherak opened this issue Mar 14, 2019 · 12 comments · Fixed by netgen/ibexa-site-api#11
Closed

Add url_alias property to Location #91

iherak opened this issue Mar 14, 2019 · 12 comments · Fixed by netgen/ibexa-site-api#11

Comments

@iherak
Copy link
Member

iherak commented Mar 14, 2019

No description provided.

@emodric
Copy link
Member

emodric commented Mar 14, 2019

Throwback to $node.url_alias :)

What's the usecase? How would you generate the links in regards to siteaccess name being in the URL? We'd need a special route to generate the link with Symfony Routing.

It could be done currently with path(ezpublish.rootLocation) ~ location.url_alias, but that seems clunky at best.

@pspanja
Copy link
Member

pspanja commented Mar 14, 2019

It should be generated through the router, so siteacess should already be there and no need to take care of it manually. If we implement it through a method, it can be generated on demand.

@emodric
Copy link
Member

emodric commented Mar 14, 2019

What I meant was, what's the usecase for having the URL alias in the location object directly? You can just as well use location.id with ez_urlalias route to generate a correct link by using path or url Twig functions.

@hknezevic
Copy link
Member

Well, it could ve just an additional commodity for the developer, so you don’t need to inject the router constantly, and instead have the URL available out of the box.

@emodric
Copy link
Member

emodric commented Mar 14, 2019

Okay, so then that's not the URL alias, it's an URI (and that's not just semantics). Also, do you get the relative or the absolute URI? Do you support query params or fragments?

Also, out of the curiosity: how often do you actually generate the URLs in PHP (as opposed to Twig) that you need to inject the URL generator/router constantly in your services?

@pspanja
Copy link
Member

pspanja commented Mar 14, 2019

Both relative and absolute, and query parameters as well. Fragments probably not needed, from my POV it would be simpler to just concatenate than to have another argument.

I'm currently thinking something like (simplified):

function getUrl(array $queryParams): Url
class Url
{
    public $relative;
    public $absolute;
    public function __toString()
    {
        return $this->relative;
    }
}

Then you could write from Twig:

{{ location.url }}
{{ location.url.absolute }}
{{ location.url(params) }}

Also, out of the curiosity: how often do you actually generate the URLs in PHP (as opposed to Twig) that you need to inject the URL generator/router constantly in your services?

Actually quite often, the last use-case was JSON endpoint for a React app.

@emodric
Copy link
Member

emodric commented Mar 14, 2019

Actually quite often, the last use-case was JSON endpoint for a React app.

Okay, fair enough, for PHP it can be useful. As for Twig, how is this, which is already possible:

{{ path(location) }}
{{ url(location) }}
{{ url(location, params) }}

different from your example in terms of simplicity?

I'd rather prefer using path and url functions, since it's closer to the Symfony way of using the router.

@pspanja
Copy link
Member

pspanja commented Mar 14, 2019

Yup, that pretty much looks the same :)

@andrerom
Copy link

andrerom commented Jul 22, 2019

We've had requests for this too. Often when dealing with locations (using APIs in PHP or over REST) people have a need for the url alias as well, or techanlly being able to get the final URI (more) easily. But as comments above says, it easily gets a bit complicated in terms of params and absolute vs relative. Unsure if this has been on @bdunogier's radar yet and/or if he has some thoughts about it :)

@pspanja
Copy link
Member

pspanja commented Jul 22, 2019

We're ATM quite busy with v3 release, but I plan to look into this again once that is finished.

@ilukac
Copy link
Member

ilukac commented Nov 13, 2019

@iherak do you still need this? :))

@iherak
Copy link
Member Author

iherak commented Nov 13, 2019

Yup, I still see a use for this. As @pspanja and @hknezevic mentioned, mostly valuable for usage through PHP, and that was the original intent of this issue :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants