locomotive_plugins 1.1.0 → 1.1.1

checksums.yaml

@@ -1,15 +1,15 @@
 ---
 !binary "U0hBMQ==":
   metadata.gz: !binary |-
-    MWY0YzE2YWNmMjMzMGQxOTZmNjQzMWY5MWI1ZDhiNzAxNWY5OTczZQ==
+    YWQ1NjFhMTAyN2JmZjUyZjZmYzgzM2UxMzkwMzQxYjI1ZmQ2NDNlNw==
   data.tar.gz: !binary |-
-    YmE3OGQ3NjliNTVkN2JmYzU1OTc2MGNhZmUxM2UyNGM5NDIxZDljZg==
+    YzhhYzllOTQzMWZjYWVhNDVmZmU2ZGU4YTAxNTQ4ZjFkY2UxNDRhZg==
 SHA512:
   metadata.gz: !binary |-
-    NDdmNjhmZTljM2VkODExMDkzZTllNWFmNTZkZmM2YTQyNjkyYjg2ZTQxNGFl
-    NTFlZjE2MzJmZjc3NTk0ZjQ1ZDk4YzNhNTA0NDFiMWFmODU1NDZlMjJiZjk5
-    MDViNTgyNDE1ZjIzNjE2YjVmMWFkNjYyNGVmMjdmYzY2YTMwOWI=
+    ODM5ZTI0MGYzODEwZTgyYjVmMTU1YTFiOTIxN2UxMGFhYTgzNmJkMGY2ZWJm
+    NDE0ODU4ZDQ1ZmNmMDczNjY1MDAyMGE3ZjVhMDE1ZDMwNmI4Yzg4NjA0NDM1
+    NmNmZmM0Y2MzM2UzNjNmODk3YmE1MzYxOWVhZTYxMTMwNmIyMDE=
   data.tar.gz: !binary |-
-    MWE3MzlmNTg5MWU4NDY5Mzk3ZjI5M2ZiYTg1OWIwY2QzZWU5NDU1OTk1ZWU4
-    ZDk2OWIyNTJhMWI3OGFjZjNhYTg2OWRkYjY4ZjgyYjEwYTUyZmY3OWZmYTMw
-    ZjYzZTIzMGVkMjAwOWY4OTIxY2YzODE1YWQzMGM1Y2U3ZTY4ZDU=
+    ZTBkNWNmOWJiZTBmMzEyMGZhMWRmZGUyZGMwODBmYmViZWNmNTM4NDczMWQ1
+    NzBhZmUwN2QzMzMwODZlN2EyYTIzYzY1NzY5YTc2MjYzOWM5ZDEzNDI4NTM0
+    ODk0ZGJlYWFmYjVkODA3MGYwZjIwMjczODEwYzExYTJkMmJiMzU=

data/README.md

@@ -272,10 +272,11 @@ checked, the config hash will be as follows:
 
 Plugins can persist data in Locomotive's database through the use of Database
 Models. A Database Model is simply a Mongoid document which is managed by
-Locomotive CMS. For example:
+Locomotive CMS. To allow your model to be managed by Locomotive CMS you must
+use Locomotive::Plugins::Document instead of Mongoid::Document. For example:
 
     class VisitCount
-      include Mongoid::Document
+      include Locomotive::Plugins::Document
       field :count, default: 0
     end
 
@@ -296,12 +297,63 @@ Locomotive CMS. For example:
       end
     end
 
-Note that the plugin databases are isolated between Locomotive site instances.
-In other words, if a plugin is enabled on two sites, A and B, and a request
-comes in to site A which causes a Mongoid Document to be saved to the database,
-this document will not be accessible to the plugin when a request comes in to
-site B. Thus plugin database models should be developed in the context of a
-single site, since each site will have its own database.
+Note that the plugin databases that use the Locomtive::Plugins::Document are
+isolated between Locomotive site instances. In other words, if a plugin is
+enabled on two sites, A and B, and a request comes in to site A which causes
+a Mongoid Document to be saved to the database, this document will not be
+accessible to the plugin when a request comes in to site B. Thus plugin
+database models should be developed in the context of a single site, since
+each site will have its own database. If you require a database model the is
+avaiable to all sites then you can do so by using a regualar Mongoid::Document.
+
+### JS3 (JavaScript on the Server Side)
+
+JS3 was developed to provide a secure way to allow inter-plugin communication.
+It allows a plugin developer to provide methods and variables to any other
+plugin contained in a sandbox. For instance if you have a plugin A that
+provides user accounts and a plugin B the restricts access to a configured path
+then you may want to be able to access the accounts on plugin A from plugin B.
+To do this you would have to do the following.
+
+Plugin A: allow plugins to access users.
+
+In the plugin definition add the following:
+
+    def self.javascript_context
+      {
+        users: Locomotive::Plugins::Variable.new { Users.all }
+      }
+    end
+
+Plugin B:
+
+You have a few options here. You can access the users from ruby by doing the
+following:
+
+    plugin_object.js3_context['plugin_a_users']
+
+This will return a mongoid criteria the you can do what you want with. If you
+want the restrictions to be variable by site the you could add a javascript
+block to the config and then run that javascript code on the js3 context.
+
+    plugin_object.js3_context.eval(config['javascript_block'])
+
+You can also add other methods or variable to the context that you want only
+your plugin to have access to, each time you call js3_context you will get a
+new object. To find out more take a look at the gem
+['therubyracer'](https://github.com/cowboyd/therubyracer).
+
+Locomotive CMS also adds two helper methods to the context to help with doing
+simple database queries. The two methods are as follows:
+
+* mongoid_where(criteria, key, value) - criteria is a mongoid criteria, key
+  the the field name, and value is the query value. This method will run a
+  where query on the given field with the given value and return a mongoid
+  criteria.
+* mongoid_in(criteria, key, value) - criteria is a mongoid criteria, key
+  the the field name, and value is the query value. This method will run a
+  in query on the given field with the given value and return a mongoid
+  criteria.
 
 ### Rack App
 

data/lib/locomotive/plugin.rb

@@ -33,6 +33,7 @@ module Locomotive
         extend ActiveModel::Callbacks
         define_model_callbacks :page_render
         define_model_callbacks :rack_app_request
+        define_model_callbacks :plugin_setup
 
         around_rack_app_request :set_plugin_object_on_rack_app
       end

data/lib/version.rb

@@ -1,3 +1,3 @@
 module LocomotivePlugins
-  VERSION = '1.1.0'
+  VERSION = '1.1.1'
 end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: locomotive_plugins
 version: !ruby/object:Gem::Version
-  version: 1.1.0
+  version: 1.1.1
 platform: ruby
 authors:
 - Colibri Software
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2014-08-25 00:00:00.000000000 Z
+date: 2014-08-26 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: locomotive_liquid