cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Module IDs and relative requiring
Date Mon, 15 Apr 2013 17:01:05 GMT
Like it!


On Tue, Apr 9, 2013 at 2:12 PM, Braden Shepherdson <braden@chromium.org>wrote:

> 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