Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Widget ID does not allow an IRI #134

Open
lewellyn opened this Issue May 17, 2012 · 4 comments

Comments

Projects
None yet
1 participant

The W3C Widget specs state that the is an IRI. http://www.w3.org/TR/widgets/#the-id-attribute

Unfortunately, if I use an IRI (as other Widget implementations sanely expect), I am unable to package for WebWorks with the same config.xml.

What should I use as a Widget ID that works both for WebWorks and packagers which follow the W3C more closely here?

As an aside, it seems (theoretically) trivial to turn most IRIs into "dotted-notation names".

For example, the contrived example of http://www.somecompany.com/apps/enterprise/randomapp could become com.somecompany.apps.enterprise.randomapp fairly easily by:

  1. Drop the scheme, colon, and slashes
  2. Drop any leading "www." on the domain (but not other subdomains, since they may well be desired in the package ID generated this way)
  3. Reverse the domain name
  4. Drop any query or fragment identifiers (? and/or #)
  5. Drop any file extension at the end of the IRI (a dot followed by 2-4 characters should be sufficient)
  6. Convert any remaining slashes into dots

Note that step 5 must be done before step 6 to prevent e.g. http://www.something.com/apps/randomapp/en from losing the ".en" that it would otherwise have.

This may not be the cleanest approach of supporting interoperable IRIs at packaging time, but it certainly strikes me as one of the more obvious approaches.

I have noted that the current BBWP does indeed handle IRIs, but it does so in a way which makes it impossible to use the same Package ID for the PlayBook.

It now simply (naively) replaces all non-alphanumerics with underscores, so the example above (http://www.somecompany.com/apps/enterprise/randomapp) becomes http___www_somecompany_com_apps_enterprise_randomapp instead of the com.somecompany.apps.enterprise.randomapp I had suggested.

This may also have negative implications in the future if a vendor moves from WebWorks to another SDK for some reason. Perhaps the correct solution is to document this behavior and tell vendors who to contact when it comes time to change Package IDs because of this?

Upon further investigation, BBWP is still naive and passes the IRI-format IDs to blackberry-nativepackager which now appears to simply convert any "unusual" characters to underscores. So, the issue still exists in BBWP albeit currently masked.

@lewellyn lewellyn added a commit to lewellyn/BB10-Webworks-Packager that referenced this issue Jan 28, 2013

@lewellyn lewellyn Allow Widget IDs in IRI format. Fixes #134.
This approach allows widgets to have IRI-formatted id attributes which
comply with section 7.6.1 of "Packaged Web Apps (Widgets) - Packaging
and XML Configuration (Second Edition)". These attributes will be sanely
normalized into reverse-dotted notation common across the BlackBerry SDKs.
3ac4833

@lewellyn lewellyn added a commit to lewellyn/BB10-Webworks-Packager that referenced this issue Jan 28, 2013

@lewellyn lewellyn Allow Widget IDs in IRI format. Fixes #134.
This approach allows widgets to have IRI-formatted id attributes which
comply with section 7.6.1 of "Packaged Web Apps (Widgets) - Packaging
and XML Configuration (Second Edition)". These attributes will be sanely
normalized into reverse-dotted notation common across the BlackBerry SDKs.
eaf9783

@lewellyn lewellyn added a commit to lewellyn/BB10-Webworks-Packager that referenced this issue Feb 6, 2013

@lewellyn lewellyn Allow W3C-compliant IDs as an IRI.
Fixes blackberry/BB10-Webworks-Packager#134

This approach allows widgets to have IRI-formatted id attributes
which comply with section 7.6.1 of "Packaged Web Apps (Widgets) -
Packaging and XML Configuration (Second Edition)". These attributes
will now be sanely normalized into the reverse-dotted notation
common across the various BlackBerry SDKs.
5658e6e

lewellyn commented Feb 6, 2013

The current pull request properly handles IRIs as well as passes jake test. There is also a shiny new test for a contrived IRI which is totally valid, though a bit strange, which gives a sane "standard" reverse-dotted representation.

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