cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Braden Shepherdson <bra...@chromium.org>
Subject Re: Module IDs and relative requiring
Date Tue, 09 Apr 2013 18:12:58 GMT
Sounds good to me.

The lack of dots in the js-module name is a new restriction you'll have to
write code to defend against, but I would be surprised to see any existing
plugins violate it.

Braden


On Tue, Apr 9, 2013 at 2:07 PM, Jeffrey Heifetz <jheifetz@blackberry.com>wrote:

> I know at some point we spoke about modifying require to allow relative
> paths within a module and I'm wondering if this is still something we're
> interested in doing and if so what a reasonable spec for doing so would be.
>
> In the current plugin spec [1], under the JS module tag, we define a
> module's id as the plugin's id, mixed with the module name (provided in
> xml) joined by a ".". Thus a plugin "com.blackberry.foo" with a module
> named "bar" becomes "com.blackberry.foo.bar".
>
> This presents an odd technical problem by using the "." character as  a
> path separator but not reserving it from general use (and even encouraging
> its use elsewhere like in the plugin id). The problem is further compounded
> by not preventing names from having "."s within them. I believe the
> simplest solution is to not allow "." characters within the js-module name,
> guaranteeing that the dot separates the module name and the plugin id.
>
> The second issue arises with the desired notation for a relative path
> require. In other systems, since the "/" is used as a separator, relative
> requires are usually prefixed by "./". However since we are not using "/"
> characters as separators does this make sense? My personal feeling is yes
> since this is what our users will be used to. This means that within module
> "com.blackberry.foo.bar" require("./baz") will result in requiring the
> module "com.blackberry.foo.baz".
>
> If this makes sense to everyone, it greatly simplifies the problem since
> we will not have multiple levels and we'll never deal with ".." problems. I
> have a patch for this implementation here [2]
>
>
> 1. https://github.com/apache/cordova-plugman/blob/future/README.md
> 2. https://github.com/blackberry/cordova-js/pull/17.patch
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawful.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message