Community
Participate
Working Groups
It might be necessary for a plugin (hosted at, say, github) to pass an Orion URL to another site. So we need to know the fully qualified path of the orion instance. Simon suggested we might have metadata on every object such as OrionHome. Then someone expanding a URI template from a plugin could use this metadata to expand the template. Right now I have hardcoded parsing of window.location.href into a hostname and build fake metadata with "OrionHome" property specified. Another issue is that currently the "Location" property in our metadata is relative. This means that if a plugin wants to pass a location to another site, it's not going to be correct. We need a way to build a fully qualified path from a Location property. Simon suggested that we probably should be using fully qualified paths in the URI template rather than the relative ones, or perhaps we would have helper methods to fully qualify a path.
I currently have extension points in three places spoofing up this variable.
I think Bug 376729 depends on this. But please remove the dependency if otherwise, Susan.
(In reply to comment #2) > I think Bug 376729 depends on this. But please remove the dependency if > otherwise, Susan. Removing dependency. Having this bug implemented means we could do the hostname construction in one place for sure. But this is more a bug about making the variable available, and bug 376729 is about the parsing being wrong.
Marking M2 because this is a plugin API issue. Two issues: - making OrionHome universally available via PageUtil...so that any code that wants to pass OrionHome can get it without having to calculate it. (use cases are bug 376726, the pixlr plugin, etc. places where we want to tell another site how to get back to Orion) - deciding whether metadata.Location includes the hostname. For example, we currently have to use {OrionHome}{Location} to get a full path to something. Should this be necessary?
Taking this bug but moving it to 1.0
For 2.0 I've at least fixed the orion home calculation -- moving to 3.0 to look at whether or not an OrionHome page param is a good idea.
(In reply to comment #6) > For 2.0 I've at least fixed the orion home calculation -- moving to 3.0 to > look at whether or not an OrionHome page param is a good idea. Our current algorithm for calculating OrionHome fails in RequireJS 2.x (see bug 402976 comment #2), and we got a report of a similar problem when Orion 2.0 is used with the Dojo AMD loader. I the problem is with this pattern: require.toUrl(".")
This open bug report had a target milestone in the past. The target milestone has been removed. Please target for a date in the future or leave the target blank if it is not known.
Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg04002.html
