Download the PHP package chippyash/sdo-pattern without Composer

On this page you can find all versions of the php package chippyash/sdo-pattern. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Informations about the package sdo-pattern

chippyash/SDO-Pattern

Quality Assurance

PHP 5.6 PHP 7 Build Status Test Coverage Code Climate

The above badges represent the current development branch. As a rule, I don't push to GitHub unless tests, coverage and usability are acceptable. This may not be true for short periods of time; on holiday, need code for some other downstream project etc. If you need stable code, use a tagged version. Read 'Further Documentation' and 'Installation'.

Please note that the Travis build servers sometimes have a wobbly and thus the build status may be incorrect. If you need to be certain, click on the build status badge and checkout out the build for yourself.

See the Test Contract

What?

This library supplies the Service Data Object (SDO) pattern. SDOs have a long history and provide a way to abstract out the process and operation on retrieving and sending data to some remote service endpoint. That endpoint can be a file, a database, a REST service etc.

Essentially, you are not interested in where the data resides, only in using it. The SDO pattern abstracts out the fetching and sending process to allow you to concentrate on using the data in some internalised format.

There is a long discourse on implementing SDOs in PHP written by Zend that describes a much more complex SDO infrastructure than is provided in this library. Personally, I've never had the need to get complicated with SDOs, but it's there if you need it.

The library is released under the GNU GPL V3 or later license

Why?

This pattern has emerged through many years of repeating the same thing:

There are some key elements to a SDO if you ignore the complexity of session storage and potential caching of SDOs in flight:

When

The current library provides the basic tools for creating SDOs, primarily the required interfaces. Also included is an abstract SDO which you can extend for your concrete implementation. Simple mappers, validators and transports are provided. An example script is also provided to give you a flavour of how to implement them.

If you want more, either suggest it, or better still, fork it and provide a pull request.

Check out ZF4 Packages for more packages

How

Coding Basics

An SDO requires three things in order to operate effectively:

The following is based on a simple scenario:

Transport

The TransportInterface dictates two methods:

The supplied chippyash\SDO\Transport\File gives us what we need, and takes a single construction parameter, the path to the file.

Mapper

The MapperInterface dictates two methods:

The supplied chippyash\SDO\Mapper\Json gives what we need.

Validator

The ValidatorInterface dictates one method:

The chippyash\SDO\Validator\Passthru validator simply returns true for any data it is asked to validate, and is used for our example.

SDO

The SDOInterface dictates

For our example we can create a simple SDO by extending the AbstractSDO and constructing it with

    class FooSDO extends AbstractSDO {}

    $sdo = new FooSDO(
        new FileTransport(__DIR__ . '/test.json'),
        new JsonMapper(),
        new PassthruValidator()
    );

To read and write data we can use:

    $obj = $sdo->fetch()->getData();
    $obj->bar += 1;
    $sdo->send();

The AbstractSDO also supports proxying the getData() method via the magic __invoke method, so we can also read and write thus:

    $sdo->fetch();
    $sdo()->bar += 1;
    $sdo->send();

This clearly is closer to true SDO usage.

It is not beyond the wit of a PHP dev to create a descendent SDO that is totally self managing, caching locally when required, fetching and sending only when required. In my day job, we have all of this and service classes that manage whole collections of SDOs. Numb nuts upstream change the incoming payload; we just change the validator (if necessary, see below). Change the endpoint; we change the transport. Want to change the way you represent the data internally; change the mapper.

On Mappers, consider using the Assembly Builder or Builder Pattern if you need to create complex data structures.

On Validators, code defensively. Validate only what you expect to use and ignore the rest. That way, when they change the payload without telling you, you don't care (assuming they leave what you want in it!). Consider using Functional Validation

You can find the source in example/example.php.

Changing the library

  1. fork it
  2. write the test
  3. amend it
  4. do a pull request

Found a bug you can't figure out?

  1. fork it
  2. write the test
  3. do a pull request

NB. Make sure you rebase to HEAD before your pull request

Alternatively, raise a ticket in the issue tracker

Where?

The library is hosted at Github. It is available at Packagist.org

Installation

Install Composer

For production

add

    "chippyash/sdo-pattern": ">=3,<4"

to your composer.json "requires" section

For development

Clone this repo, and then run Composer in local repo root to pull in dependencies

    git clone [email protected]:chippyash/SDO-Pattern.git chippyash-sdo
    cd chippyash-sdo
    composer install

To run the tests:

    cd chippyash-sdo
    vendor/bin/phpunit -c test/phpunit.xml test/

License

This software library is released under the BSD 3 Clause license

This software library is Copyright (c) 2015-2018, Ashley Kitson, UK

History

V1.0.0 Original release

V2.0.0 BC Break: namespace change from chippyash\SDO to Chippyash\SDO

V2.0.1 update examples

V2.0.2 Add link to packages

V2.0.3 verify PHP7 compatibility

V2.0.4 update build scripting

V3.0.0 BC Break. Withdraw support for PHP <5.6

V3.1.0 Change of license from GPL V3 to BSD 3 Clause


All versions of sdo-pattern with dependencies

PHP Build Version
Package Version
Requires php Version >=5.6
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package chippyash/sdo-pattern contains the following files

Loading the files please wait ....