You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think it would be helpful to be able to jump between the Routes*.yaml files and controller actions or classes.
Obviously there is a bit of flexibility in using the routes, but I would imagine
click on defaults.@controller value to go to @package/…@subpackage/…@controllerController
click on defaults.@action value to go to the corresponding action if available
maybe have gutter icons in the controller class that show the routes that could be matched, e.g. with the resolved name (Package :: (Suffix :: )+ Name) and a link to the file
A more powerful interpretation of the pattern could be interesting, but probably a bigger task. Things like completion for routeParts or subRoutes based on the placeholders in the pattern...
Unfortunately resolving the sub-routes with merged defaults is a bit annoying, I imagine.
However after that I think the framework does do some shortcuts in resolving the class names; in general it might be interesting to have a utility to get paths, manifest etc. by package-key, but I think that's not strictly necessary here.
The text was updated successfully, but these errors were encountered:
I think it would be helpful to be able to jump between the Routes*.yaml files and controller actions or classes.
Obviously there is a bit of flexibility in using the routes, but I would imagine
defaults.@controller
value to go to@package/…@subpackage/…@controllerController
defaults.@action
value to go to the corresponding action if availablePackage :: (Suffix :: )+ Name
) and a link to the fileA more powerful interpretation of the pattern could be interesting, but probably a bigger task. Things like completion for routeParts or subRoutes based on the placeholders in the pattern...
Unfortunately resolving the sub-routes with merged
defaults
is a bit annoying, I imagine.However after that I think the framework does do some shortcuts in resolving the class names; in general it might be interesting to have a utility to get paths, manifest etc. by package-key, but I think that's not strictly necessary here.
The text was updated successfully, but these errors were encountered: