Design of path alias

In Yii 1.x, a path alias is in the format of "path.to.xyz". For example, system.web.CController

In Yii 2.0, we plan to use a new format (the old format will no longer be supported). This is based on our 1.x experience and some feature requests.

A general format of Yii 2.0 path alias is: "@rootAlias/path/to/xyz"

For example, @yii/base/Component.php
By calling Yii::setPathOfAlias(), one can register a root alias.
And by calling Yii::getPathOfAlias(), one can convert a path alias into a path with the root alias part replaced with the registered path.
Both of these are similar to Yii 1.x.

The reason we introduce the '@' prefix is because it will allow us to more easily detect if a path is an alias or not.
And by using '/' instead of '.', our path aliases have more freedom to represent a path (previously, one cannot have '.' as a normal char in a path alias).
Moreover, the new path alias format can allow us to represent not only file path, but also URLs.
For example, if we define '@yiiframework' => 'http://yiiframework.com', then '@yiiframework/doc' can be turned into 'http://yiiframework.com/doc'. This should be very useful, I believe.

It seems to me, the reason you ran into problems/limitations with the original syntax, is because it was too simple and based on various assumptions about needs. Now you've extended the assumptions to include support for URLs, but it doesn't feel like a great solution to me, because it's still based on assumptions about a limited number of uses.

I like the approach taken by the stream handlers in PHP. Of course, we're not dealing with streams here, but we are dealing with resources, and the Uniform Resource Identifier is the de-facto standard for identifying resources.

You're trying to expand your custom resource-identification scheme to include URLs, which are just one type of URI - this to me is an indication that you're working backwards; from a limited, non-standard scheme, to a single kind of URI, just one of a broad spectrum of resource-types supported by the URI scheme.

It doesn't look to me like you can even fully support URL with this syntax? For instance, '@yiiframework/doc/api/1.1/CAttributeCollection#properties' works for a URL, but won't work for a file path - so you're mixing two different types of "resources" (using one "alias") that are incompatible.

The benefit of URI, is that type of resource is explicit rather than implied - "http://" clearly means it's a web-address, while "mailto:" clearly identifies an email address, and "yii:" clearly defines an entirely different kind of resource.

The interpretation of each kind of URI is well-defined, yet fully flexible.

The last example (with no resource-type at the start) would imply a default resource-type, which might be called 'alias', so it would be the equivalent of, say 'alias:components/MyClass' - which would be interpreted at run-time the way aliases are interpreted now, searching for a root-alias, then a module, etc.

Each type of resource would need a handler of some sort - some handlers may implement an interface that Yii::getPathOfAlias() can use to obtain a path, some may implement an interface that enables Yii::getUrlOfAlias() to obtain a URL, and others might implement who-knows-what.

Providing a lower-level interface like Yii::getResource($uri) would enable you to identify a type of resource at run-time, and enable you to interact with that resource in different ways.

Other example of candidates for resources:

Images - for example, given a URI like 'image:cat.jpg?320x200', Yii::getUrlOfAlias() might give you 'http://site.com/images/resized/cat_320x200.jpg', while Yii::getPathOfAlias() might give you '/webroot/protected/files/images/resized/cat_320x200.jpg'.

Controllers and actions - for example, given a URI like 'app:posts/show/4', Yii::getUrlOfAlias() might give you 'http://site.com/post/4-article-title', while Yii::getPathOfAlias() might give you '/webroot/protected/controllers/PostController.php'.

@Antonio Ramirez: you're right. Using app params has the same effect. This new syntax is just an alternative way to prefix a URL.

@mindplay: the main reason for this new syntax is not about supporting URL (even though it does so). The idea is very simple: replace the root alias in a path with a predefined prefix. The path can be anything, file path, URL, or anything else, as long as '/' is used as separator and there is a valid root alias. We can find this need in many places. The reason for the '@' character is to differentiate it from non-aliased path.

What you proposed is something different and may probably cause confusion: alias and protocol are two different things. Maybe I don't fully understand you, but I'm a bit confused at what problem you are trying to solve.

// throws an error in case is not a valid URL
Yii::setPathOfAlias( array('@yiiframework'=>'http://www.yiiframework.com','validator'=>CUrlValidator) );

This way, we could make sure dynamic aliases are valid ones...

Another requirement surfaces, demonstrating that you are dealing with a type of resource.

@qiang: what I'm suggesting is that your paths and/or aliases are in fact just resource identifiers - some users wish to expand that concept to include URLs, and Antonio here even wishes to validate URLs as an extra means of achieving early failure, something I strongly prefer over late failure, which is much harder to debug.

What I'm suggesting, is that adding support for "@" to disambiguate aliases may be too short-sighted. Next, you'll be adding "#" to disambiguate URLs, and so forth.

Rather than adding one particular, very specific resource-type discriminator in the form of an "@" character, why not take the full plunge and use a standardized resource-identifier format, such as URI?

Instead of "@", use "alias:" which is more concise - and make the alias scheme-interpreter it's own separate entity, so we can expand on the concept as needed, extending or replacing scheme-interpreters and adding new ones if required.

I could write up some stub code if this still doesn't make sense to you.

The idea that "everything is a resource" is the driving force behind REST, and certain interesting frameworks (such as OpenRasta and InfoGrid) build on the concept of resource-identifiers backed by resource-handlers. Everything begins with the URL, which is just another resource.

You may be right to think that this kind of thinking is overly complicated for Yii's needs - I'm not trying to lead a revolution or completely change the idea of Yii, I'm just throwing this thought on the table for discussion... It may have certain useful aspects, or it may not :-)

mindplay, how often do you need resource identifiers for paths in your applications?
The KISS and Occam's razor principles tell that we should not code something unless we know the reason for it.
Can you provide a few real-life use cases?

qiang, will there be an way to define custom set of aliases in config?
Maybe there should be a callback API, so that mindplay could implement his resource mappng?

mindplay, how often do you need resource identifiers for paths in your applications?
The KISS and Occam's razor principles tell that we should not code something unless we know the reason for it.

You're probably right - this is most likely overkill.

I'm just not a fan of overloading methods at run-time - especially with behavior that parses out strings and changes behavior based on some custom string-syntax. It feels dirty. It always makes me think I'm doing something wrong, and I should have solved the problem by designing an API that supports what I'm trying to do, instead of trying to roll it into some existing function by parsing strings. You know what I mean?

On the one hand, we're replacing the alias resolution system with an '@' prefix and '/' instead of '.'. I see mindplay's point though, although it adds a potential for a load of complexity. One option would be to simple implement as planned but use "alias:" as the opening token, which would give the option of adding that flexibility without changing the API later.