Re: [dart-web] Relative or absolute package import paths?

[David Notik]

Anyone?

And in fact, pub build confirms that absolute paths are at least frowned upon (it's a warning, but says "not allowed").

[Warning from ImportInliner on woven|web/index.html]:

web/index.html:12:5: absolute paths not allowed: "/packages/polymer/polymer.html"

Thank you for any guidance!

--
Woven
http://woven.co
206-351-3948

@DaveNotik

On Fri, Aug 22, 2014 at 4:34 PM, davenotik <dave...@gmail.com> wrote:

To clarify, basically I mean everything. Polymer imports, static references, references to the Dart/JS scripts, etc.

If my server serves the app at /, all is swell, but if it serves it at /item/whatever, suddenly all the relative URLs are thrown off.

Do I really have to convert all my relative paths everywhere to absolute paths? That would suck.

--D

On Friday, August 22, 2014 3:46:31 PM UTC-4, davenotik wrote:

AFAIK, it's advisable to use relative paths for package imports:

http://goo.gl/IekZWT

Do you mean specifically for <link rel="import"> and Polymer.dart ?

Yes.

--
You received this message because you are subscribed to a topic in the Google Groups "Dart Web Development" group.
To unsubscribe from this topic, visit https://groups.google.com/a/dartlang.org/d/topic/web/szLsH84BpQo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to web+uns...@dartlang.org.
Visit this group at http://groups.google.com/a/dartlang.org/group/web/.

To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/465d8f36-e23e-4703-8e31-217bd62784c0%40dartlang.org.

[Bob Nystrom]

On Sat, Aug 23, 2014 at 9:23 PM, David Notik <dave...@gmail.com> wrote:

And in fact, pub build confirms that absolute paths are at least frowned upon (it's a warning, but says "not allowed").

[Warning from ImportInliner on woven|web/index.html]:

web/index.html:12:5: absolute paths not allowed: "/packages/polymer/polymer.html"

Just to clarify, this warning is coming from a polymer transformer, not pub build itself. So pub doesn't frown on absolute paths, but polymer may.

- bob

[Siggi Cherem]

The reason we request to use relative and not absolute paths, is that it makes it possible to also support loading apps in Dartium even without running a server (using file:/// urls). Anyone writing a shared library will likely use relative paths to be able to support this use case.

Do I really have to convert all my relative paths everywhere to absolute paths? That would suck.

I hope not. In fact, it might not always be possible, for example, if code in other packages use relative URLs and you can't change their code.

You can probably work around the problem if you have the server respond to any URL containing 'packages/', for example not just '/packages/' but also 'mydir/packages/'. Alternatively, if all the URLs are on your code, then you could include a prefix on every css and image URL, and set the value of the prefix when you load the entrypoint (for example '{{prefix}}/packages/bar'). Note that HTML imports don't need this, because we inline and remove HTML imports from your app during the build step. 

 

Just to clarify, this warning is coming from a polymer transformer, not pub build itself. So pub doesn't frown on absolute paths, but polymer may.

Correct - polymer transformers right now do not allow absolute paths. However, it might be possible to make transformers more flexible in the future.

I just opened a new bug to make sure we look into ideas that can make this better, for example, maybe the build step can convert relative paths into absolute ones (see https://code.google.com/p/dart/issues/detail?id=20691)

Cheers,

Siggi

[Siggi Cherem]

On Tue, Aug 26, 2014 at 2:04 PM, David Notik <da...@woven.org> wrote:

Ok, so in order to get the app served properly when on URLs like item/whatever, including both pre and post build, I had to handle not only packages/ but also index.html and index.dart and their post build assets like index.html_bootstrap.dart.js (luckily, all those are nicely prefixed with index.html). 

My code, see line 45: https://gist.github.com/DaveNotik/79bfc9455c742ec4f7af

This seems so bizarre. There has got to be a better way. Thoughts?

I'm surprised you need to handle those separately too. I might be missing something, but I thought they should always come at the same URL location. Is there something strange happening with the routing logic itself? 

--D

On Mon, Aug 25, 2014 at 3:54 PM, David Notik <da...@woven.org> wrote:

Great insights. Thank you Siggi! I'll try your server handling idea, and follow that bug.

--D

--
You received this message because you are subscribed to a topic in the Google Groups "Dart Web Development" group.
To unsubscribe from this topic, visit https://groups.google.com/a/dartlang.org/d/topic/web/szLsH84BpQo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to web+uns...@dartlang.org.
Visit this group at http://groups.google.com/a/dartlang.org/group/web/.

To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/CAJmP2_rG%2BFjzyDnr71834jk9DHyydwpwj22UGf-3uT%2BiKOJ-9g%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Dart Web Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web+uns...@dartlang.org.

Visit this group at http://groups.google.com/a/dartlang.org/group/web/.

To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/CACekCDkLhPStz%2BsD3KXga0ZHh2S38hYDahvfTW%3DH42_qPQx%3D8g%40mail.gmail.com.

[ntaoo.g]

As AngularJS adopts with their html5mode, using base tag may also useful for PolymerDart SPA with pushState.

https://docs.angularjs.org/error/$location/nobase

I have not tested it enough to be functional with PolymerDart. And I'm sorry if it is obsolete solution.

I'm happy if I can hear comments about this idea.

Regards,

[davenotik]

I'm still dealing w/ this long-standing issue, and was hoping I might be enlightened with a better way.

You go to /foo, and _handleAlias (a handler in my Shelf server) confirms it is a valid (user or community) alias (exists in database, not physical dir) and it sends back the (Polymer) app, i.e. index.html. That index.html calls all its imported assets (dart, js, css...) but it's now relative to /foo (e.g. /foo/packages/browser/dart.js) which is wrong. Previously I had ugly code (https://gist.github.com/davenotik/d970f5a05a586f4b5cf8) to rewrite these assets, but I was hoping I could find a better way w/ this refactor. Any ideas?

I set <base href="/"> which works and has broad browser support, but it's still client side and I worry there may be repercussions (I noted this issue for one: https://github.com/webcomponents/webcomponentsjs/issues/329).

Thank you!

--D

[David Notik]

So I think I hit one of those repercussions I suspected.

http://d.pr/i/18ClU

Refused to execute script from 'http://my.app/confirm/packages/web_components/webcomponents.js' because its MIME type ('text/html') is not executable, and strict MIME type checking is enabled.

Notice it's looking for that file off of /confirm which is the alias the browser happens to be at. It seems webcomponents.js and dart_support.js are automatically injected by the polyfill, and thus don't respect the base href. So they end up serving up my homepage, not their JS, causing this MIME type error.

Polymer 0.15.5+4

--D