cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Braden Shepherdson <bra...@chromium.org>
Subject Re: cordova templates?
Date Fri, 14 Mar 2014 14:02:33 GMT
To be clear, you're suggesting that we have templates in the form of
plugins? I'm not sure that's what we really want. At least, if we install
them like regular plugins then there are several values that need to be
changed, including the directory name.

Perhaps cordova template add org.apache.cordova.template.hello-world
my.new.plugin.id and it does the appropriate renaming at install time?

No comment on template.* namespace vs. foo.bar.template.baz or whatever. If
we're going to allow templates as pseudo-plugins, why not allow anyone to
publish a template? Users may have good ideas for templates that would be
useful to themselves, and maybe to others as well.

Braden


On Fri, Mar 14, 2014 at 8:23 AM, Jonathan Bond-Caron <
jbondc@gdesolutions.com> wrote:

>
> Thoughts supporting starter templates like plugins?
>
>  e.g. Something like this:
>
> cordova template add apache.hello.world
>  (plugin.xml)
> cordova template add apache.hello.world.native.dude  (plugin.xml)
>
> Internally it's a:
> cordova plugin add template.apache.hello.world
>
> Reserve template.* namespace?
>
> Bonus is there's an indication of which starter templates people are using.
>
> There's some minor implementation details like:
> cordova template add apache.hello.world
> cordova plugins ls
> [template.apache.hello.world]
> [org.apache.cordova.statusbar]
> [org.apache.cordova.console]
>
> What we'd probably want is:
> cordova plugins ls
> [org.apache.cordova.statusbar]
> [org.apache.cordova.console]
>
> Templates can only install, can't update.
> Users publishing a template - yes / no?
>
> > -----Original Message-----
> > From: brian.leroux@gmail.com [mailto:brian.leroux@gmail.com] On Behalf
> Of
> > Brian LeRoux
> > Sent: March 11, 2014 1:05 PM
> > To: dev@cordova.apache.org
> > Subject: Re: [cordova-plugins/statusbar] Publishing as core
> >
> > I like this idea. Achieves all concerns. (Separation thereof, and
> onboarding ease.)
> >
> >
> > On Tue, Mar 11, 2014 at 9:04 AM, Carlos Santana
> > <csantana23@gmail.com>wrote:
> >
> > > +1 Keep it as a plugin not embed into platform repo
> > >
> > > default plugins ?
> > >
> > > what about binding a set of default plugins with our www template app
> > > (the template app specified what plugins are required)
> > >
> > > meaning associate a set of plugins with a template www app, and not
> > > associate with platform or cli
> > >
> > >
> > >
> > >
> > >
> > > On Tue, Mar 11, 2014 at 10:37 AM, Andrew Grieve <agrieve@chromium.org
> > > >wrote:
> > >
> > > > Plugins allow us to share JS. Rolling statusbar into platforms means
> > > > different JS for all platforms, and make it easier for the APIs to
> > > diverge.
> > > >
> > > > Plugins allow us to share docs, and to have the docs live with the
> code.
> > > > APIs like Android's "app" plugin don't have very good docs (or maybe
> > > > they are just undiscoverable, or maybe I've just missed where they
> > > > are). But having consistency with docs is a big win I think, so
> > > > having statusbar
> > > as a
> > > > plugin means devs can go to its plugin page to find its docs.
> > > >
> > > > I think just having default plugins would achieve the "everyone will
> > > > probably want it" concern. But having it show up in "cordova plugin
> ls"
> > > > will help devs discover that it's there and that they should
> > > > probably use it.
> > > >
> > > >
> > > > On Tue, Mar 11, 2014 at 8:49 AM, Jonathan Bond-Caron <
> > > > jbondc@gdesolutions.com> wrote:
> > > >
> > > > > On Mon Mar 10 04:07 PM, Jesse wrote:
> > > > > > More on the concept of rolling into a platform ...
> > > > > > My distinction is that there are some things that every platform
> > > should
> > > > > consider a
> > > > > > baseline of browser functionality, and if the OS SDKs do not
> > > > > > provide
> > > it
> > > > > out of the
> > > > > > box, then we should. Some examples of this :
> > > > > >
> > > > > > 1. Local XHR, Windows Phone does not support xhr when trying
to
> > > access
> > > > a
> > > > > file://
> > > > > > url, I could have made this a plugin that would only be used
on
> > > > > > WP,
> > > but
> > > > > I think
> > > > > > this functionality should be intrinsic, so now it is.
> > > > >
> > > > > +1
> > > > >
> > > > > > 2. console.log: if you create a brand new iOS cordova project,
> > > > > > the
> > > > > hello-world app
> > > > > > gives you some boilerplate code to get started.  One thing that
> > > > > > new
> > > > > users may
> > > > > > notice is the use of console.log in index.js, however, they
will
> > > never
> > > > > see the
> > > > > > output.  Hooking conosle.log output to go to the command-line
> > > > > > output
> > > of
> > > > > a run
> > > > > > command, or the output window of visual studio, or xcode is
the
> > > minimum
> > > > > > functionality, and I personally think it should be built in.
> > > > > > This is
> > > > > probably best
> > > > > > discussed in a new thread, as I know Michal has a different
> > > > > > opinion,
> > > > > because of
> > > > > > some weinre edge case, but this is meant to serve more as an
> example.
> > > > > >
> > > > >
> > > > > Yep agree, distinction here is there's ~ "web dev" flow and
> > > > > "native
> > > dev"
> > > > > flow (using an IDE)
> > > > >
> > > > > Both of those should be core somehow
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Carlos Santana
> > > <csantana23@gmail.com>
> > >
>

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