ledger_sync 1.4.2 → 1.4.4

data/documentation/site/reference/architecture/clients.md

@@ -1,33 +0,0 @@
----
-title: Clients
-weight: 1
-layout: reference
----
-
-## Overview
-
-Clients handle the authentication and requests to the ledger.  A ledger may have different authentication strategies,
-so clients will accept different arguments.  For example, QuickBooks Online utilizes Oauth 2.0 while NetSuite offers
-Token Based Authentication.  While similar, the required keys are different.
-
-## How to use
-
-Unless you are customizing LedgerSync, you will always pass an instantiated client to an object (e.g. an operation).
-The object will handle using the client as needed.
-
-## Gotchas
-
-### Oauth 2.0
-
-Clients store the authentication details for the ledger.  Given that Oauth 2.0 tokens can refresh during a request,
-these clients will handle saving credentials back to the client instance.  Typically (though some clients offer
-more automated solutions), you will want to save any changes back to your database.  You can use
-`client.ledger_attributes_to_save` to retrieve a hash of which attributes to save. Your code to do so could look like
-the following:
-
-{% highlight ruby linenos %}
-# Assuming `client` is defined as an instance of a ledger Client class
-client.ledger_attributes_to_save.each do |attribute_to_save, value|
-  # Store value
-end
-{% endhighlight %}

data/documentation/site/reference/architecture/index.md

@@ -1,14 +0,0 @@
----
-title: Architecture
-excerpt: Understand the high-level architecture of LedgerSync.
-layout: reference
----
-
-LedgerSync consists of the following high-level objects:
-
-- [Clients](/guides/architecture/clients)
-- [Resources](/guides/architecture/resources)
-- [Serialization](/guides/architecture/serialization)
-- [Operations](/guides/architecture/operations)
-- [Searchers](/guides/architecture/searchers)
-- [Results](/guides/architecture/results)

data/documentation/site/reference/architecture/operations.md

@@ -1,6 +0,0 @@
----
-title: Operations
-weight: 4
-layout: reference
----
-

data/documentation/site/reference/architecture/resources.md

@@ -1,38 +0,0 @@
----
-title: Resources
-weight: 2
-layout: reference
----
-
-## Overview
-
-Resources are named ruby objects (e.g. `Customer`, `Payment`, etc.) with strict attributes (e.g. `name`, `amount`, etc.).  LedgerSync provides resources specific to each ledger.  While it is possible to create your own resources (see Customization for more details), this section refers to provided ledger-specific resources.
-
-The library strives to make each resource and attribute name match the ledger API.  This naming convention will help you more readily match ledger documentation to LedgerSync resources.
-
-## How to use
-
-Resources are primary used as the inputs and outputs of operations and searchers.  A resource is passed to an operation along with a client.  Once the operation is successfully performed, a duplicated and updated resource is returned.
-
-Resources have two layers of validation:
-
-1. The Resource
-2. Operations
-
-When instantiating a resource, validations are performed.  These validations include class checks and, if necessary, value checks (e.g. enums).  When performing an operation, validations are performed based on what attributes are required for the operation to be successful.  For example, the `ledger_id` should be `nil` on `create`, but it should be present on `update`.
-
-## Available resources
-
-You can see all resources available for a given ledger by calling `resources` on the ledger's `Client` like so:
-
-`LedgerSync::Ledgers::QuickBooksOnline::Client.resources`
-
-This returns a hash of resource types to classes, where the resource types are unique (e.g. `customer`, `vendor`, etc.).
-
-You can see all resources available in LedgerSync by calling `LedgerSync.resources`.  This returns an array (note: not a hash as multiple ledgers have the same types) of resource classes that have been created inheriting the `LedgerSync::Resource` class.
-
-## Resource Attributes
-
-Resources have defined attributes.  Attributes are explicitly defined.  An error is thrown if an unknown attribute is passed to it.  You can retrieve the attributes of a resource by calling `Customer.attributes`.
-
-A subset of these `attributes` may be a `reference`, which is simply a special type of attribute that references another resource.  You can retrieve the references of a resource by calling `Customer.references`.

data/documentation/site/reference/architecture/results.md

@@ -1,6 +0,0 @@
----
-title: Results
-weight: 6
-layout: reference
----
-

data/documentation/site/reference/architecture/searchers.md

@@ -1,6 +0,0 @@
----
-title: Operations
-weight: 5
-layout: reference
----
-

data/documentation/site/reference/architecture/serialization.md

@@ -1,6 +0,0 @@
----
-title: Serialization
-weight: 3
-layout: reference
----
-