Currently volo appcache generates a manifest that contains files such as .gitignore. These will likely become broken links when served disabling the offline mode.

I suggest this patch:

Index: volofile
===================================================================
--- volofile    (revision 6493)
+++ volofile    (working copy)
@@ -223,7 +223,9 @@
                 appFiles = appFiles.map(function (file) {
                     var start = file.indexOf('/' + buildDir + '/');
                     start = (start !== -1) ? (start + 11) : 0;
-                    return file.substr(start, file.length);
+                    var baseName = file.substr(start, file.length);
+                    var shouldIgnore = baseName.match(/^\.|\/\./);
+                    return shouldIgnore ? undefined : baseName;                    
                 });

                 master = master

The plan is to use this format to create new projects:

volo create poop http://mozilla.github.com/mortar/builds/app-stub.zip

This should trigger the "onCreate" method in the volofile in which we should trigger "npm install" to automatically install the necessary modules for the volo commands.

As of January 1 2019, Mozilla requires that all GitHub projects include this CODE_OF_CONDUCT.md file in the project root. The file has two parts:

1. Required Text - All text under the headings Community Participation Guidelines and How to Report, are required, and should not be altered.
2. Optional Text - The Project Specific Etiquette heading provides a space to speak more specifically about ways people can work effectively and inclusively together. Some examples of those can be found on the Firefox Debugger project, and Common Voice. (The optional part is commented out in the raw template file, and will not be visible until you modify and uncomment that part.)

If you have any questions about this file, or Code of Conduct policies and procedures, please reach out to [email protected].

(Message COC001)

The list and the repo treat age-old templates the same way as new ones, leading people to believe they are all up to snuff.

Can we separate out the ones that are in "do not use" state for now?

The library we're using for localisations in privileged apps is a temporal intermediate step between the old Fabien's webl10n and something new and improved called L20n that will be released sometime.

We should keep an eye on that and update/replace those with L20n when it's released.

"I have a simple HTML shell and a few DOM nodes, now where do I put my JS code?"

It makes sense It's currently unclear which JS framework we should use for the purpose. backbone.js, Shipyard, require.js, ... come to mind. We'll need to strike a balance between unobtrusiveness/simplicity and helpfulness at getting started quickly and knowing "where things go".

Research different options and make a suggestion.

Some requirements are here:
https://ecosystem.etherpad.mozilla.org/6

At the very least initially, we'll use Twitter Bootstrap as a simple, responsive, design framework. Make a simple HTML5 shell that uses Twitter Bootstrap and sets up the JS framework we decide on.

The www directory is not focused enough on open web apps for Firefox OS. The more files we have laying around there the more confusing it gets.

Let's remove:

• README.textile
• apple-touch-icon-*
• crossdomain.xml (no Flash in open web apps, please)
• humans.txt (nice concept, but unlikely to be of much use for beginning developers)

STR:

1. install firefox nightly
2. install Firefox OS Simulator
3. volo create appday-demo mozilla/mortar-list-stub
4. volo serve
   5.1. open Firefox OS simulator, and use browser open http://YOUR_IP:8008/
   or
   5.2 click "Add directory" and select manifest file to install packaged app
5. click "+" to add something in myapp

expected:
show a form for add something

actually:
nothing happened

in app.js, we write:

require.config({
    baseUrl: 'js/lib',
<%- js_require_cfg %>
});

and jquery is included from:

'lib/jquery'

That won't work. If js/lib is the base URL, then this needs to be simply "jquery". And all separate scripts (!) will need to be underneath js/lib.

A few things we hit that we should triage later on:

• The build process wasn't replacing the script tag to include app.js instead of require.js. This should be fixed now, but should test this
• The baseUrl: "js/lib"config value was required because the build command assumes this same setting. This also requires that everything is under js/lib, do we want that?
• The require.js setup is hard to explain
• Porting current apps to require.js is a little painful

(Sorry if this isn't the right place to file this, there are many repos.)

I just tried using a <textarea> in an edit page, instead of an <input>, and whatever magic applies to <input>s doesn't seem to apply to <textarea>s. This was all based on the mortar-list-detail example.

When saving, the values on the model aren't set correctly and the form fields aren't cleared. Switching the <textarea> to an <input> and changing none of the JS works as expected.

We probably need that either here or in each separate child project.

Manifest file validator recommends adding 60x60px icon as they are needed for Firefox OS.
Without 60px icon there is no default icon for apps installed in Firefox OS

Hi. I think these templates is useful. but I found warning message "deprecated".
I'd like to know what the new structure template would be like.
Can you give me a rough idea of the new structure?
thanks.

I think the template has been integrated with mortar on dmose's repo, so need to find it and officially integrate it.

It's confusing to have that unrelated file there, and it's also somewhat malformed when shown on github. I suggest we just remove it.

We should still give credit to HTML5 Boilerplate in our own README, of course.

Much like playdoh vs. funfactory, we should decide whether just forking mortar is the way to go or if mortar should in itself be a command to spin up a new project directory.

volo looks like an apt solution for this purpose.

https://github.com/volojs/volo

Check out if it serves our purposes here. @jrburke should be able to answer any questions.

The README links to: https://github.com/mozilla/mortar/archive/master.zip

Sadly, that does not pull in submodules, so the ZIP file is essentially useless. git subtrees might be what we want, or some JavaScript XHR magic on gh-pages. Anyway, this ZIP file does not actually contain the code.

x-tags are bundled by default (and should probably be a git submodule or so), so that volo command isn't useful anymore.

Plus, it's currently broken.

Make a specific landing page that triggers the install process

Every Open Web App needs a manifest file. Create a dummy one that shows how it's done, or find another viable way to encourage and simplify manifest creation.

... and why you should care about/want them

https://github.com/mozilla/?query=mortar

The list is pretty much the same as linked to here, except mortar-layouts, which is defunct and should probably be renamed to reflect that.

volo appcache creates manifest.appcache, but manifest.webapp reads:

"appcache_path": "/cache.manifest",

One of these should change.

This is more a question than a request: our require.js code currently includes jQuery off the Google CDN. When developing locally (via file://) this file is downloaded over and over again (I think) and significantly slows down development.

Also, given appcache, is it even a good idea to rely on the Google CDN for actual open web apps that are supposed to work offline? I don't think jquery is added to the appcache file when we volo build, currently?

Once we have solid specs for packaged apps, mortar should facilitate turning an app into such a package (which may be as easy as running the build step, then zipping up the output, but we'll see).

When we use ghdeploy, the webapp will inevitably land in a subdirectory of the user's github subdomain. For an app install from there to work correctly, the following line needs to be added to the manifest:

"launch_path": "/my-app/",

Granted, not every mortar user wants to deploy to github. We could add it automatically when running ghdeploy (after all, this is json, so we could parse and add, then write the output to www-ghdeploy/manifest.webapp), perhaps?

When using external (CDN) scripts with require, they work locally.

After using volo build, the minified app does not work anymore: uncaught exception: undefined missing https://marketplace-cdn.addons.mozilla.net/mozmarket.js

I have no idea why that would be the case. @jrburke, anything obvious?

Maybe I'm doing it wrong...

Steps to Reproduce:

1. Install master branch
2. npm install ejs
3. bash ./bin/build app-stub helloworld
4. cd helloword
5. npm install volo
6. export PATH=$PATH:node_modules/.bin
7. volo build

Actual:
ERROR: Malformed volofile [...] Error: Cannot find module 'volo-ghdeploy'

So I did

8. npm install volo-ghdeploy

Now I get

ERROR: ReferenceError: q is not defined
    at Object.run (/home/ozten/mortar/helloworld/volofile:165:13)

Per install docs, this is no longer working:

git clone ...
cd mortar
npm install

The package.json file is not in the root dir. What changed? I tried to cd into default-project and run npm install but I get:

Error: No 'name' field found in package.json

Something that mortar should come with by default is code to install the app easily. This library looks promising:

https://github.com/wavysandbox/install

We should integrate that.

We might want to look out how js is structured with requirejs. Currently I don't think there's any way to load any files outside of /js/lib/ which might be a downside.

Need some designer love here or the app list looks boring when having several of these templates in the AppManager

We're suggesting people uncomment certain link and script tags in index.html to get x-tags and friends up and running, but volo build will not pick up these files.

Instead, one needs to @import them in app.css (for CSS) and add those files via require(['file1', 'file2']); in app.js (for scripts) for them to be picked up.

This seems a tad more complicated, but might just be a matter of putting comments in the right spots. Plus, this way minification comes for free because volo figures it all out for you.