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

Create ~ helper for joining to the baseURL #1816

Closed
matthewp opened this issue Jul 29, 2015 · 3 comments
Closed

Create ~ helper for joining to the baseURL #1816

matthewp opened this issue Jul 29, 2015 · 3 comments
Assignees
Milestone

Comments

@matthewp
Copy link
Contributor

This will be used to join to the root, for example images:

<img src="{~ 'images' status 'indicator.png'}" />

will convert to:

<img src="https://somecdn.com/images/complete/indicator.png" />

If the module loader's baseUrl is https://somecdn.com/

~ path...

This will typecheck for StealJS/SystemJS, RequireJS, to get the module loader baseUrl, and fallback to document.baseURI to use as the base url that the arguments are joined to.

If the path is relative it will use the module's path, if available. #1817 is needed for that functionality.

@matthewp matthewp self-assigned this Jul 29, 2015
@matthewp matthewp added this to the 2.3.0 milestone Jul 29, 2015
@rjgotten
Copy link

This will typecheck for StealJS/SystemJS, RequireJS, to get the module loader baseUrl,

The base URL of the module loader is not necessarily the base URL of a website.
It's common to root JS module loader at a subpath holding scripts: http://www.example.com/scripts/, especially when using far future expires headers coupled with a cache-busting version in the path: http://www.example.com/scripts/1.0.0/

The domain/authority part is not necessarily the base URL of a website either as you can host individual applications inside subdirectories. E.g. http://www.example.com/apps/myapp1 and http://www.example.com/apps/myapp2.

Application-relative URLs (the term used by Microsoft, which has been using a leading tilde for these type of URLs since the first version of ASP.NET) are best handled in user code, by having users describe how the base application url should be mapped.

E.g. using RequireJS, the following does the job:

<head>
  <script>
  // First create a module mapping for the '~' symbol to
  // a domain-relative, protocol-relative or absolute root
  // url. (Don't make it path relative! That won't work!)
  require.config({
    map : { "*" : {
      "~" : "/application/."
    }}
  })
  </script>
</head>
define([ "require" ], function( require ) {
  // Then use the `require.toUrl()` method.
  // In this case, it will produce "/application/content/images/example.jpg"
  var fullUri = require.toUrl( "~/content/images/example.jpg" );
});

@matthewp
Copy link
Contributor Author

Great point. We can allow the user to set a variable, probably can.baseUrl which will be used as the first check to get the application base url for cases where the module loader baseUrl is not the same.

matthewp added a commit that referenced this issue Jul 31, 2015
The ~ helper is used to create urls (for `<img>` for example) that are
bound to the root of your application or relative to the current module.

If the lookup is relative, such as:

```
{{~ "../hello/world.svg"}}
```

This will lookup the location relative to the current template module
(if using Steal).

Otherwise it will lookup the location through, in descending importance:

* can.baseUrl
* System.baseUrl (if using Steal/System)
* location.pathname

Fixes #1816

Includes docs
matthewp added a commit that referenced this issue Aug 3, 2015
The ~ helper is used to create urls (for `<img>` for example) that are
bound to the root of your application or relative to the current module.

If the lookup is relative, such as:

```
{{~ "../hello/world.svg"}}
```

This will lookup the location relative to the current template module
(if using Steal).

Otherwise it will lookup the location through, in descending importance:

* can.baseUrl
* System.baseUrl (if using Steal/System)
* location.pathname

Fixes #1816

Includes docs
matthewp added a commit that referenced this issue Aug 4, 2015
When server-side rendering a separate loader is created that represents
a loader that is actually loading the application in a browser. If the
renderingLoader is present we should use it, and use its baseURL. This
closes out #1816
matthewp added a commit that referenced this issue Aug 4, 2015
When server-side rendering a separate loader is created that represents
a loader that is actually loading the application in a browser. If the
renderingLoader is present we should use it, and use its baseURL. This
closes out #1816
@matthewp
Copy link
Contributor Author

matthewp commented Aug 4, 2015

This is in minor.

@matthewp matthewp closed this as completed Aug 4, 2015
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

No branches or pull requests

2 participants