WIP (do not merge!)- Type relative URIs, Template relative URIs #901
Conversation
|
This work is to address #873 |
| /// | ||
| /// This converts URIs within a document from relative URIs to being absolute | ||
| /// URIs. | ||
| class AbsoluteUris { |
There was a problem hiding this comment.
Why a class if everything is static ?
There was a problem hiding this comment.
Depends on how this code is to be exposed- if it's an internal utility (as it is now), then top-level methods are probably correct. If it becomes a part or is re-exported like the rest of the code here then there's too much pollution of the top-level namespaces and the class namespacing is cleaner.
I'm ambivalent and can change, primarily looking for feedback at this time on how URIs should behave.
| /// https://github.com/Polymer/platform-dev/blob/896e245a0046a397bfc0190d958d2bd162e8f53c/src/url.js | ||
| /// | ||
| /// This converts URIs within a document from relative URIs to being absolute | ||
| /// URIs. |
There was a problem hiding this comment.
By convention we use /** ... */ for multi-line comments, would you mind switching ?
|
Is this blocked on anything? Could you walk me through this on VC? |
|
Would be happy to walk through on VC, will try to explain some here for others as well. The first part is that URIs on annotations are considered relative to the type on which the annotation resides. Basically it gets the URI of the type (actually the library) by using mirrors to get to LibraryMirror.uri, which it then combines to find the absolute URI. It then normalizes these package-relative URIs (currently to the form '/packages/'). URIs on types which are in web/ or test/ (non-package-relative) become relative to the entry point of the application. This package normalization is important because I assume that there will need to be a separate uri resolver which translates from the normalized package syntax ('/packages/') to be non-root-relative- most likely relative to the location of the main script entry of the app. Next part is making the URIs of HTML and CSS files be relative to their source locations. Currently it's doing it in two steps, the first step is parsing the HTML fragment within the context of a document with the base URI set to the original location of the HTML, second step is modifying all fragment-relative URIs to be absolute URIs (using the absolute_uri's lib). Outstanding questions:
@cbracken also mentioned that he'd be interested in lending a hand on this, as he's currently running into a number of URI issues. |
Making template and CSS URIs relative to the library in which the type which is annotated resides. Also making all URIs within the template and CSS files be relative to those files.
- Changed AbsoluteUris to be top-level methods rather than all statics. - Clarified unittest for Image by setting attributes rather than src directly. - Changed multi-line comments format from /// to /** syntax
- package-relative URIs are now 'packages/' rather than '/packages/'. - Support for mirrorless mode with a transformer. This transformer generates one large table for type->URI lookups. - Integrated with tip-of-tree Angular This generates a global table of type to URI lookups
|
Further progress, mirrorless support is now in. Remaining items:
|
|
Awesome progress sir. On Mon, Apr 21, 2014 at 6:29 PM, blois [email protected] wrote:
|
|
I've got a working patch for the expression extractor on top of this (rebased to latest master) here: |
|
My branch is pretty close to ready. I'll rebase and give a run through this afternoon. |
|
Superseded by 1238 /cc @TedSander |
Making template and CSS URIs relative to the library in which the type which is annotated resides. This resolves the template and CSS URIs against the type's location.
Also this leverages some code from Polymer to make the loaded HTML contents and CSS be relative to those files.
The two changes are separable, but I think it makes sense to at least discuss in parallel:
Primary work remaining- support for the static case.