Create ~ helper for joining to the baseURL #1816

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

Comments

Projects
None yet
2 participants
@matthewp
Contributor

matthewp commented Jul 29, 2015

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

This comment has been minimized.

Show comment
Hide comment
@rjgotten

rjgotten Jul 30, 2015

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" );
});

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

This comment has been minimized.

Show comment
Hide comment
@matthewp

matthewp Jul 30, 2015

Contributor

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.

Contributor

matthewp commented Jul 30, 2015

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 matthewp referenced this issue in donejs/deploy Jul 30, 2015

Closed

Deploy Superissue #19

7 of 9 tasks complete

matthewp added a commit that referenced this issue Jul 31, 2015

Implement ~ helper
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

Implement ~ helper
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

~ helper: use renderingLoader.baseURL
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

~ helper: use renderingLoader.baseURL
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

This comment has been minimized.

Show comment
Hide comment
@matthewp

matthewp Aug 4, 2015

Contributor

This is in minor.

Contributor

matthewp commented Aug 4, 2015

This is in minor.

@matthewp matthewp closed this Aug 4, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment