With the latest Meteor version 0.5.9 I've been experimenting with the appcache package, and really like its functionality.
I used meteor create --example leaderboard and then meteor add appcacheto test out the behaviour, and the page even loads when the server is not running at all! Super cool!
However, the database does not seem to be cached? When the server is not running
Players.find().fetch()
returns
[]
This is quite a showstopper for me, as I'm making a notes app where the notes need to be available offline as well. Am I missing something or is there an alternative method of getting database data when offline?
Look at the Ground:DB Package for this use. This package makes client side caches of subscribed collections.
https://atmospherejs.com/ground/db
Example of a collection that will get populated by Meteor subscriptions (subscribe call required separately)
localCollection = new Ground.Collection('mongoName');
Example of disconnected Collection (so you have to populate it yourself)
disconnectedCollection = new Ground.Collection('localName', {connection:null} );
The appcache package doesn't cache your data. See the docs:
The appcache package stores the static parts of a Meteor application (the client side Javascript, HTML, CSS, and images) in the browser's application cache.
[...]
(Note however that the appcache package by itself doesn't make data available offline: in an application loaded offline, a Meteor Collection will appear to be empty in the client until the Internet becomes available and the browser is able to establish a livedata connection).
At this point the appcache package is purely meant to improve loading speed of your app by caching static resources. See the meteor wiki:
The appcache package is only designed to cache static resources. As an "application" cache, it caches the resources needed by the application, including the HTML, CSS, Javascript and files published in the public/ directory.
Related
In my Meteor project, Can I have app/client/abc.js AND app/server/abc.js and expect meteor to handle them graciously?
Yes. File names in meteor are not currently meaningful apart from manipulating load order. See the structuring your app section of the docs.
Yes you can have abc.js in both client and server folders. However, /client/abc.js will be loaded only on client, whereas /server/abc.js will be loaded only on server.
I'd like to host the TimeLineJS library on my Meteor app locally and not use the smart package because I need to fine tune it. I've tried declaring the createStoryJS function in the Meteor space like this in create Timeline.js. However, there are other dependencies (storyjs-embed.js, storyjs-embed-generator.js, storyjs-embed.js, and everything under locale) which rely on the document object on the browser. How can I ensure that Timeline.js is loaded in a template with all of its dependencies locally managed, while successfully accessing the window.document object?
Put all the files in client/compatibility in your app, such that the dependencies load first via Meteor’s load order (e.g. put dependencies in client/compatibility/lib, for example). That’s all you have to do: no script tags, no declaring anything. Initialize TimeLineJS within a template’s onRendered callback.
I am just starting with Meteor and working on an existing project. I am running into an issue with one of the packages(observatory-apollo) that's has the following line:
__meteor_bootstrap__.app.use Observatory.logger #TLog.useragent
It is complaining that __meteor_bootstrap__.app is undefined.
What is __meteor_boostrap__ exactly? I can't seem to find a description of what it is but from threads, people seem to know how to use it. I can only see it defined in boot.js, but it doesn't really tell me much...
Meteor uses connect npm module under the hood for various reasons, to serve static files, for example. __meteor_bootstrap__.app was the reference to connect app instance.
Before it was __meteor_bootstrap__.app but it changed couple of releases ago and became WebApp.connectHandlers object and is part of WebApp package.
WebApp is a standard package of Meteor, core package for building webapps. You don't usually need to add explicitly as it is a dependency of standard-app-packages.
Example of usage the connectHandlers is to inject connect middlewares in the same way as you would use any connect middleware (or some express middlewares, express is built on top of connect):
WebApp.connectHandlers
.use(connect.query())
.use(this._config.requestParser(bodyParser))
You can look at meteor-router Atmosphere package and take it as an example: https://github.com/tmeasday/meteor-router/blob/master/lib/router_server.js
More about connect: https://npmjs.org/package/connect
Copying a static website, i.e., HTML, CSS, JS is very simple.
Copying a dynamic website, i.e., is difficult due to the server-side scripts.
I'm concerned about cloning any meteor app as most of the server-side scripts are eliminated and the only thing which needs to be copied is the database, the schema can be easily obtained from the meteor live app and data can be easily scraped from the existing meteor app.
If a successful meteor app can be easily cloned, no one would prefer to develop an app on meteor.
Is there a way to stop cloning an existing meteor app?
Well, technically a meteor app can be cloned it depends on your directory/file structure & whether you're using it in development mode. If you're using one file and this sort of structure to seperate your code:
if(Meteor.isClient) {
}
if(Meteor.isServer) {
}
Because this file would be sent down to the client so someone can fetch it.
So it might be better to move to this structure
/client - Place stuff in Meteor.isClient in a new js file
/server - Place your server side code in a new js file
/public - Place other public folder stuff
So no one will see the server side scripts, so they can't clone the backend of your app.
Production mode/Dev mode
In addition if you run your Meteor app in 'production mode' the Javascript is packed, handlebars & handlebars templates are precompiled.
In my opinion, it might be actually harder to copy a Meteor app to the previous types of web apps because HTML is rendered on the client side, fetching the html files will actually get back empty html files, if you even prettify the large JS file still leaves back precompiled handlebars templates. In addition files are merged into one!
So thats when it comes to cloning it to another meteor app. Even if getting the client script is available (as with any other stack) there are even more hurdles with Meteor when it comes to replicating the server script:
DDP
Attempting to clone it to a PHP/Server side script stack might be even harder because POST/GET aren't even used, DDP is used instead.
Schema
Width regards to the schema, you can control what the client sees via Meteor.publish, so they won't actually see the whole schema
How can I able to find the usage of default tables available in drupal.
Is there any documentation available?
For example: there is a table called node. I need to know what is the usage of it and how it acts.
Any suggestions or answers will be helpful and grateful.
Your question is not very clear (the term "usage" is quite ambiguous), but you could install the Devel module. After setting it up it will show, for every page loaded (home page included), which SQL queries are run.
Every module can add tables to the database. A default Drupal install uses core modules, either required ones or those installed as dependencies of the default installation profile. These modules install their own tables.
Each module declares its tables in its implementation of hook_schema. The Schema module use the information from the implementations of this hook to provide a schema documentation.
Most of the time, you shouldn't directly access the database but use the API provided by the modules managing the data. Tables are usually considered private for their modules. New release of a module may change its schema in an incompatible way. Using API is much safer. Unfortunately, sometimes database access is the only option. In these cases, implementation of a data access layer between your code and the database is advised.