I'm totally new to trigger.io and i was wondering if there was a suggested directory for putting files like zepto.js or jquery.js (if I were to use that).
In theory one can place it anywhere within the "src" directory tree. However, I would suggest placing it in the "js" directory. Or even better... to help separate your .js files and 3rd party .js files... place it in a "js/lib" subdirectory. Most (if not all) of the trigger.io examples in their documentation and Github tend to do this.
https://github.com/trigger-corp
https://github.com/amirnathoo
One of the great things about developing applications using trigger.io (or Phonegap) is that you can utilize your existing web programming knowledge and best practice.
Still... at the end of the day its up to you to decide how to organize your application. With smaller apps it might not be that important, but as your application grows having a "clean" and manageable structure helps.
Update: In their weather app tutorial they use a "resources" directory.
http://docs.trigger.io/en/v1.3/tutorials/weather/tutorial-2.html
Related
I need to do some research if/how to use backend code from some already available Java web service in some newly created Windows 10 UWP app. The Java code deals with parsing special binary data, depends on things like configuration files and some additional 3rd party libs like Apache Commons*. The current ideas are either providing some native DLL to be bundled with the UWP-app or providing a stand-alone one publishing some high level web services which the UWP-app consumes.
I came across iKVM and CodenameOne and read that iKVM itself is not maintained anymore, but CodenameOne forked a version for their own purposes. At various places authors say that that version of iKVM is managed in the official GitHub repo of CodenameOne, but I'm unable to find it there. The only thing I find are some helper implementations and formerly committed DLLs in the repo-history and such, but nothing which looks like the complete forked project.
Any idea where I can find this? Obviously I'm missing something...
I would simply like to have a look at what CodenameOne needed to change, how much effort they put into keeping up with Java 8, what of those efforts went back to the original project etc.
Thanks!
Sorry about that. I was under the wrong impression that the code resided in the Ports/UWP directory but apparently it isn't there. I'm probably the person who wrote that in those places...
We added a link to the actual repo there for reference. It's here: https://github.com/shannah/cn1-ikvm-uwp
I see that there is already an answer to this question but I feel its outdated. Many things have changes since then. There are now modules, cloud_endpoints and webapp2. What should be the good directory structure for my project which allows me to add/modify features easily.
For example I should be able to manage:
Modules.
Cron jobs.
Task queues.
Cloud endpoints.
I'd first take a look at modules, at least for these reasons:
modules really are in many respects (almost) equivalents to entire (single-module) apps in older docs/references, so once a module's position in the app's hierarchy is clarified various posts referencing an app-context can usually be extrapolated to just a module-only context.
nowadays an app can use different languages/sandboxes for different modules (see Run both Java and PHP on google app engine project) or even for different versions of the same module (see Google App Engine upgrading part by part)
Personally I'd stick with the recommended multi-module app structure - each module having its own directory, one level below the app's directory:
The app's top dir would hold the per-app configs (which aren't applicable to a particular module): dispatch.yaml, cron.yaml, index.yaml, and queue.yaml. Note that the cron jobs and task queues definitions belong here (but nothing stops you from routing/dispatching various cron jobs to various modules based on the requested paths).
I'd also place in the app's top level dir any files/directories I'd like to share across multiple modules in the DRY way. These files/dirs would be shared by a module by symlinking them inside the respective modules so that the module gets its own copy at deployment. Almost anything that can exist as a separate file or directory can be shared this way:
templates, images, scripts, CSS, macros, datastore models definitions, python modules - whatever you need
3rd party libs, for example How do I access a vendored library from a module in Python Google App Engine?
even portions of the module's .yaml configuration! for example: Do I need to copy `skip_files` across multiple YAML files?
Finally the recommended files/dir structure of a particular module may further depend on the module language/sandbox, the framework(s) used, the developer's style/preferences, etc. I don't think it's possible to provide a one-size-fits-all recommendation which would be effective/acceptable in all cases.
Endpoints are just RPC (strongly typed) versions of basic REST url's with the added advantage that they can be used to Generated client side libraries. So the endpoint config and definitions belong in the SAME directory as the module (ie mobile-backend) as their REST counterpart would. In other words, if you have (or would have) a REST endpoint in Module1 for "user login", then you should put the "user login" Endpoint in the module1 directory. Further, if you don't like the symlink approach, you can move your module1.yaml file UP one level and then that whole module can import from a "common" directory.
I am migrating from Eclipse to Android Studio and have a Android App connected to AppEngine.
I have split the Server side into two modules (default module for Endpoints and user facing requests) and "admin" module for backend stuff.
Now both these modules need to use the Entities. (backend module usually is responsible for saving these entities to DB, while the frontend default module is the one who returns data back to Android using these Entities).
What is the best way to share these Entity classes between these two modules in Android Studio? (also making sure these classes get enhanced etc). I do not wish to have duplicate classes, both in the default module as well as admin.
Maybe have a common "java" module shared between the two (but not sure class enhancing would work). Or should the admin module NOT use the Entities and instead use other ways of persistence?
Appreciate your thoughts.
While there may be reasons for not sharing the code, personally I prefer DRY.
I solved the issue in DRY spirit with the Python backend by placing the models definition file in the app dir app/models.yaml and sym-linking it into each of the modules subdirs app/module_blah/models.yaml, thus ensuring all modules see the same models definitions. At deployment time the symlinks are automatically replaced with the actual content of the file being symlinked. From appcfg.py update:
The command follows symlinks and recursively uploads all files to the
server. Temporary or source control files, such as foo~, .svn/* are
skipped.
Care may be needed to deploy all modules at the same time.
I used the same technique to also share entire libraries with common code across modules, by symlinking app/lib/libX subdirs into the desired app/module_blah/lib/libX as needed.
Not sure if this technique is usable in Java, tho.
I created a web2py app that is extremely light, with the goal of eventually making the app support JSON-RPC calls, and maybe a few other things.
I found some tutorial online that (on winxp) had me get the source code for web2py and extract it on top of the compiled program. At the top level, I edited app.yaml with my program name and used the GAE SDK to upload the program. It looks like that uploaded everything including example applications. I think it's including a whole gluon directory, and other dir's full of py files. Is there a way to setup web2py to only upload my application, and what's minimally required to run it?
The app.yaml that comes with web2py includes a section skip_files and it should contain, among others, this line:
(applications/(admin|examples)/.*)|
You can change it to
(applications/(admin|examples|welcome)/.*)|
So that welcome app is not deployed. You add more apps that you may have and do not want deployed.
At minimum you need:
web2py/gaehandler.py
web2py/gluon/* (and subfolders, this is web2py)
web2py/applications/theoneappyouwanttodeploy/* (and subfolders)
In a production deployment, you wouldn't have your /app folder in the public webroot; it only takes one sloppy fingered mistake to turn private business assets such as PHP files into plaintext on the web. The advanced and production installation instructions in the book describe how to topologically isolate the webroot directory, so you can make folders containing PHP files readable only by you. This technique has worked great for me for a while - but now I want to use and develop plugins.
The CakePHP book omits the discussion of plugins in production deployments. For those of you that use CakePHP in production with plugins, how do you make the assets in a given plugin's webroot directory publicly accessible?
Do you create a plugins folder in webroot and then symlink plugins/my_plugin_name to the plugin webroot? Do you manually copy the plugin webroot folder into webroot? Do you bite the bullet and just relocate the plugins folder to webroot? Do you use some kind of fancy content feeding plugin?
What's the best solution?
Sounds to me like you should manually copy files from the plugin webroot to your own webroot. If it's in production, I presume you aren't going to be turning the plugin on/off frequently (as one might do in development), so this would be a one-time process.
Also, doing it this way keeps your private assets out of publicly-accessible folders, maintaining the security you are concerned about.
On the other hand
If the plugin is open source, take the easy way out and drop that whole sucker in the webroot. If it get's compromised, you shouldn't really care, since the files are freely distributed anyway.