Download the PHP package liip/dataaggregator without Composer

On this page you can find all versions of the php package liip/dataaggregator. 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 dataaggregator

UNMAINTAINED

This bundle is no longer maintained. Feel free to fork it if needed.

Liip DataAggregator

Current Travis Status

Build Status

Purpose

The DataAggregator provides a structured way to fetch/retrieve information form different sources, process this information, and to persist it even to several destinations at once. To be able to archive this it is build on a threefold of component types:

Furthermore the goal of this library is to be as small as it can be providing the most and simplest way to be extended and altered to ones' personal needs.

The managing component - the aggregator

The aggregator is the heart of the library. Since itself do not have any knowledge about the structure of the information shared between a loader and a persistor it takes care of the connection between those two and manages their interaction. Being a simple registry loaders and persistors get attached to it and run iteratively. Since it shall not have any knowledge about the transfer format it should not process nor alter the information it passes through.

The information fetching/retrieving component - the loader

The name already unveils to purpose of this component. It has all knowledge of how to extract information from a request or response. The source and format of the data is loader specific. Still following the idea of haveing a footprint as lean and small as possible the interface of a loader requires only two methods. One (load()) to actually extract the data from a response and a second (stopPropagation()) to notify the aggregator hat it might be a good idea to stop invoking every other reggistered loader. This might be the case when a loader was setup as a filter mechanism and the result being return is already empty.

The information storage - the persistor

The purpose of the persistor is to make the information retrieved from the aggregator permanently available. This also means that the loader and persistor must have the same idea about the information passed between them. Furthermore it is possible for the persistor to process the data to be stored.

Special flavors

Hybrid

Imagine an implementation acting towards a loader as an aggregator and towards an aggregator as a loader. This makes it possible to encapsulate a specific set of sources to one loader and provide the collected and probably already process information to the aggregator on the 1st level of your implementation. This makes it even easier to reuse loaders and persistors and should encourage you to follow all the nice oop principles out there (SOLID, DRY, ...).

Transformers

As the sketch shows the transformers are a more general approach to create a special transfer format (like e.g. a Doctrine entity) form the loaded data. This makes it much easier for an invoked persistor to do his work. Further a dedicated data validation can be introduced in the named transfer format.

Concept sketch

Installation

The source is now PSR-0 compatible. There is no specific installation routine to be followed. Just clone or checkout the source into to your project and use it. In case you don't use a PSR-0 compatible autoloader, you only have to add the bootstrap.php into your bootstrap or autoloader.

Composer

Add the following lines to your composer.json file and update your project's composer installation.

This composer configuration will checkout the 'cutting edge' version ('dev-master') of the project. Be alarmed that this might be broken sometimes.

NOTE: In case you do not know what this means the composer project website is a good place to start.

Github

Thus I recommend the composer way to make DataAggregator a dependency to your project. The sources are also available via github. Just clone it as you might be familiar with.

Logging

This project does for different reasons favor Monolog for the logger of choice. Unfortunately Monolog does not implement the Psr\Log\LoggerInterface. Therefor an Adaptor was implemented to bring the two worlds together. So in case you want to use a monolog logger use the MonologAdaptor as dependency instead of monolog directly.

Update 2013-01-12: @gnutix brought to my attention that Monolog just added support for the Psr-3. This is actually good news, it soon will be possible to get rid of the formerly introduced MonoLogAdaptor. Kudos to everyone involved in that achievement.

Validation

The DataAggregator provides the base to introduce validation in to a loader, persistor and/or an entity (aka an instance of the class representing your transferred data).

Plain validator

The idea behind a validator is to verify constraints are met by a value of a variable. Therefore theu interface defines the »validate« method usually throwing an exception if any constraint is not met. In case a decision other than handling an exception is needed the »isValid« method shall return a boolean indicating the validation has been passed (true) or not (false).

Validator strategies

A strategy is a set of validators. Each of them bound to a specific type or classname a validation shall be invoked on.

Dependencies

Suggestions

All versions of dataaggregator with dependencies

PHP Build Version
Package Version
Requires beberlei/assert Version >=1.5
psr/log Version ~1.0
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 liip/dataaggregator contains the following files

Loading the files please wait ....