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

Dev: Project URI Parser #5930

Open
MGatner opened this issue Apr 28, 2022 · 9 comments
Open

Dev: Project URI Parser #5930

MGatner opened this issue Apr 28, 2022 · 9 comments
Labels

Comments

@MGatner
Copy link
Member

MGatner commented Apr 28, 2022

We have a lot of places where values can be interpolated into a (project) URI. There are also some places that it would be good to add support for such URIs.

I would like to add a new class that handles these centrally, probably a child of URI and maybe merged with the idea of a “project-specific” URI class.

See also: #5923 (comment)

@iRedds
Copy link
Collaborator

iRedds commented May 2, 2022

Why do we need a new class if the URI class is already designed to parse the url?
Just add a URI::is($uri) method that will check for a match.

@lonnieezell
Copy link
Member

I would agree that I'm not a fan of creating another URI class. I feel that could be confusing. Granted, I'm also a little confused on what you mean by "project specific" URI class.

@kenjis
Copy link
Member

kenjis commented May 2, 2022

I also don't understand what exactly "project specific" URI and "URI meta-segment transformation" are.

@MGatner
Copy link
Member Author

MGatner commented May 2, 2022

So clearly I haven't explained this well 😅 Maybe "parse" isn't the right word: translate? interpret?

So within Router we have the ability to define a URI like {locale}/foo/bar - this is understood as "a URI within this project using the current locale". What I would like is two parts:

  1. Separate handling for "internal URIs" (this has been discussed lots, see project roadmap and closed PRs)
  2. The ability to use these "segment variables" like {locale} anywhere in the framework.

Does that help?

@kenjis
Copy link
Member

kenjis commented May 2, 2022

In CodeIgniter context, URI has two meaning.

  1. generally speaking URI like https://codeigniter.com/controller/method
  2. The URI path after index.php like controller/method

This class handles 2, doesn't it?

@lonnieezell
Copy link
Member

Why does this need a new class? Can't we add placeholder support to the existing URI class and use that? I would expect that info to be available on the one that the IncomingRequest class has.

@kenjis
Copy link
Member

kenjis commented Feb 13, 2023

I don't know if this is the same as Project URI Parser, but I have come to the view that it would be better to have SiteURL class that extends the URI class representing the site (current) URL.

@kenjis kenjis mentioned this issue Feb 14, 2023
5 tasks
@MGatner
Copy link
Member Author

MGatner commented Feb 15, 2023

Yes, that's precisely the point. Though the intent was to handle more than just the current URL, but also routes, etc

@kenjis
Copy link
Member

kenjis commented Feb 16, 2023

Yes, {locale}/foo/bar is kind of URI path in the project, and it is corresponding to the real route path en/foo/bar.
However, I don't know how SiteURI relates to this route or Routing classes..

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

No branches or pull requests

4 participants