mozilla / mortar Goto Github PK
View Code? Open in Web Editor NEWINACTIVE - http://mzl.la/ghe-archive - A collection of web app templates
Home Page: https://wiki.mozilla.org/Apps/Mortar
License: Apache License 2.0
INACTIVE - http://mzl.la/ghe-archive - A collection of web app templates
Home Page: https://wiki.mozilla.org/Apps/Mortar
License: Apache License 2.0
volo appcache creates manifest.appcache, but manifest.webapp reads:
"appcache_path": "/cache.manifest",
One of these should change.
STR:
expected:
show a form for add something
actually:
nothing happened
Need some designer love here or the app list looks boring when having several of these templates in the AppManager
... and why you should care about/want them
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 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.
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.
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).
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?
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.
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.
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.
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.
(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.
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.
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.
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
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
Maybe I'm doing it wrong...
Steps to Reproduce:
Actual:
ERROR: Malformed volofile [...] Error: Cannot find module 'volo-ghdeploy'
So I did
Now I get
ERROR: ReferenceError: q is not defined
at Object.run (/home/ozten/mortar/helloworld/volofile:165:13)
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?
"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
We probably need that either here or in each separate child project.
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?
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.
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.
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:
If you have any questions about this file, or Code of Conduct policies and procedures, please reach out to [email protected].
(Message COC001)
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.
Make a specific landing page that triggers the install process
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:
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.
A few things we hit that we should triage later on:
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?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.
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.
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?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.