Ya, more I've thought on the more I think as long as we're using the
config.xml (or likewise some manifest) as the canonical src for the concat
then this should be an ok convention.
While we are concatenating everything today its easy to know what's in
there *because* we concat _everything_. In th
I don't see what the problem is with having all plugins concatenated in one
file. I'd even go further and say that we should just concatenate all of it
in cordova.js (that is what is happening right now with core plugins).
We would not be disallowing people from having multiple script tags if they
Something else along these lines we should consider - is providing a
grunt.js file in the default template when you run cordova create. It could
have a watch task that copies files from the root www/ into platform www/
directories whenever a file changes.
On Fri, Nov 23, 2012 at 10:29 AM, Gord Ta
I have always had a vision that the build step for cordova.js would make it
into the app build step.
Currently the packager has most of the functionality to bundle in plugins /
platform specific code / core modules.
With a little bit of work it could be made to be driven off of the plugin's
folde
just considering this, I suppose we could say that cordova.js is a build
artifact, and the manifest is the 'truth' of the install (from the issue
tracking perspective)
On Fri, Nov 23, 2012 at 3:09 PM, Braden Shepherdson wrote:
> I'm happy adding multiple script tags. We could require plugins to
I'm happy adding multiple script tags. We could require plugins to be
wrapped up for AMD, instead, and just include them in the index page.
I don't think a single file makes the reproducibility any worse: you still
need to have the exact set and versions of plugins that anyone else has.
And it's
So, we have a build step no matter what. Currently we concat the whole go.
When we have the many plugins world doing a fat concat is dangerous
business for issue tracking. My cordova.js very likely won't be the same as
yours. Moving this into a second file has the same problem.
Script loaders are
On Thu, Nov 22, 2012 at 3:36 PM, Gord Tanner wrote:
> This also is feeding into some of the work we are doing with ripple.
>
> Ripple will serve up the app and host it kind of like how we do
> debug.phonegap.com for in browser testing.
>
> Sent from my iPhone
>
> On 2012-11-22, at 3:15 PM, Filip
This also is feeding into some of the work we are doing with ripple.
Ripple will serve up the app and host it kind of like how we do
debug.phonegap.com for in browser testing.
Sent from my iPhone
On 2012-11-22, at 3:15 PM, Filip Maj wrote:
> Agree with Jesse.
>
> Automatically adding the plu
Agree with Jesse.
Automatically adding the plugin's .js to html pages inside a www dir can
be done by the cordova-client tool anyways.
Agree this should go to vote before we proceed.
On 11/22/12 12:13 PM, "Jesse" wrote:
>I think all the refresh stuff is super cool, I will share how I work,
>so
I think all the refresh stuff is super cool, I will share how I work,
so you can get another perspective.
90% of my code is written on localhost, either running directly in a
browser to work out UI stuff.
When I need access to actual device APIs, I simply put a redirect in
my index.html.
This gets
So for the last while I've been working on making the edit-refresh cycle
faster when one is working on the web part of a Cordova app. We can't do
much about the native side, but there must be a faster way than saving the
code, switching to Eclipse/Xcode, rebuilding and deploying.
There are two par
12 matches
Mail list logo
