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
Related
I have a Cmd-generated 6.0.2 application that is running at about 200 customers on-premise servers. I would like to allow the customers to select a base color and a text color, (e.g. #c0ffee and #facade), and call an API running on our server (not on a dev PC!), that takes the SCSS, sets $base-color:dynamic(#c0ffee) and $color:dynamic(#facade), generates the resulting CSS and returns that to the customer, where it is stored on the server alongside the app.
It is really easy to implement this by copying the whole project, including the javascript sources, to the server, calling sencha app build production, and then return the content of the generated CSS files. But since it's a server API, I would like to reduce the footprint, by not always compiling and then discarding the javascript, and at best, not even needing the javascript on the server.
It would be really nice if someone could tell me how I can, using sencha Cmd, generate a single SCSS file that contains all styles required for the app, such that I would only have to search/replace in that file the $base-color and $color definition, and how to, after successfully replacing it, call sencha fashion to only generate a single new CSS file from that SCSS file.
Per the Meteor docs, I'm trying to determine which special folder to place non-app assets (ex. Photoshop design PSDs) in, so that they still get checked into source control but don't get wrapped into the eventual client or server payloads.
It feels 'wrong' to use tests/ for this purpose but the docs suggest it has the desired behavior. Can private/ be used similarly, or will its contents always get added to the server bundle regardless of whether your app code registers any Assets? (Or is there a better place altogether to put such files?)
Consider a project structure like this:
/YourMeteorProject
/YourPSDFiles
file1.psd
file2.psd
...
/YourMeteorApp
/.meteor
/client
/server
...
You can launch your meteor app from within /YourMeteorApp. Files that are not part of your application, such as your PSD files, are kept outside of the application.
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.
All,
Sorry in advance - I'm a total novice when it comes to ASP.net.
I'm working on a project that's fairly simple. I have single HTML page that collects input from the user. When the input is complete - the html page uses AJAX to post the data to a web service. That service receives the data, does some processing on it, then sends back a response.
The "client" part of this app is pure HTML/Javascript (not ASP.net), and is complete and works perfectly.
The "service" part of this app (MyHandler.ashx) is built using ASP.net. Technically - what it does is receive data from the AJAX post. It then uses Microsoft.Office.Interop.Excel to open an Excel spreadsheet, pass the users' inputs into that spreadsheet, then retrieve several calculated values from the spreadsheet, and returns those values in the response to the AJAX post.
Using Visual Studio VS I've got this whole process running locally on my PC.
When I "publish" the project - VS creates a ton of files. I sent those files to the team that manages the server; they deployed them, and voilà - it works. (The necessary Office interop libraries are installed on the server).
So - my question - as I make a few modest changes (e.g., validation, error handling) to the handler - MyHandler.ashx - which of those published files actually change? If i want to reploy - do I simply need to resend an updated version of MyHandler.ashx? Or, do simple coding changes to that file require changes to the DLL?
I guess my question is, generally - what's in the DLL? (E.g., is it a compiled version of MyHandler.ashx?)
More specifically - publishing my project creates the following files that I don't really understand:
Web.config
Global.asax (in my project, there's not much in here)
bin/MyProject.dll
So, if I make changes to MyHandler.ashx - can I simply reploy THAT file? Or, do I need to "publish", then "redeploy" thd dll? (By changes - I mean simple code changes, not decisions to include/exclude other external dependencies).
Sorry - this question must seem like nonsense to knowledgeable ASP.net developers. But, with other technologies I've used, things were clear:
If you're developing a Flash project, you write source code in .FLA files, then compile, then deploy the resulting .SWF files.
If you're developing an HTML/JavaScript/PHP project, you write those files, then deploy those same files
I'd trying to get a better understanding of what's what with ASP.net.
Thanks again.
The DLL contains the compiled code behind the ASHX file. The ASHX is just a service definition for an HTTP handler. When you make changes to the service (e.g. the code), simply issue another Publish like you did before and send the entire package.
But in short, when you change the code, the DLL is what's changing.
In Meteor is there a way to include a js file in another js file.
Specifically, server side and most importantly at start up.
The use case I am running into is for complicated Meteor.startups where I need to load quite a bit of data to the mongodb into a variety of collections.
In order to have different test scripts I have to have more than one file each with duplicate data.
So, is there anyway to have say a boostrap.js file that calls Meteor.startup and then is able to load different files in order to load up the test data?
Or can this be done in a different way through some kind of object?
By design Meteor will automatically include all the javascript files in the the entire project (except in the public folder) but only segregate them between the server and client.
You could create objects in separate files and just use the functions or objects whenever you please, they should all be available at startup.
Try using my module loader made for use with Meteor. It's very similar to AMD: https://github.com/matb33/meteor-smd