Download the PHP package dsawardekar/encase-php without Composer

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

Encase Build Status

Lightweight IOC Container for PHP.

Encase is a library for using dependency injection within PHP applications. It provides a lightweight IOC Container that manages dependencies between your classes. It was written to assist with wiring of domain objects outside Frameworks to build faster test suites.

A Ruby implementation is here.

Features

Usage

Consider a Worker class that has a dependency on a Logger. We would like this dependency to be available to the worker when it is created.

First we create a container object and declare the dependencies.

Then we declare that the Worker has a dependency on logger using the needs function. It returns an array of keys that correspond to keys we registered on the container.

That's it! Now we can create a new Worker by looking up the worker key on the Container.

The Worker instance gets a reference to the logger automatically.

Container Configuration

Containers are configured using a functions object, factory or singleton. Container items are stored in an associative array inside the container and are used to lookup the object later.

The types of items your can store in the Container are listed below.

Object

Objects are pre existing values that have already been created in your system. They can be strings, numbers or any value that does not require instantiation.

They are stored in the Container and returned as is without any modification. To store objects call the object function. And pass a string key to store under, along with the object itself.

Factory

A Factory container item is a Classpath string. On every lookup a new instance of this Class will be created with it's dependencies auto-injected.

To store such classes use the factory function. And pass the full classpath to the Class to be instantiated.

Singleton

A Singleton is similar to a Factory. However it caches the instance created on the first lookup and returns that instance on subsequent lookups.

Use the singleton function to store the path to the singleton Class.

Declaring Dependencies

To specify dependencies of a class, you use the needs function. It must return an array of strings corresponding to the keys stored in the container.

You can optionally use the INeeds interface to declare the needs.

Lazy Initialization

Encase allows storage of dependencies lazily. This can be useful if the dependencies aren't ready at the time of container configuration. But will be ready before lookup.

Lazy initialization is done by passing a closure or callable to the container instead of a value. Here key's callable will be evaluated before the first lookup.

The closure or callable takes an argument equal to the container object itself. You can use this to conditionally resolve the value based on other objects in the container or elsewhere in the system.

Initializers

Initializers are useful when working with objects from external libraries that don't use the Encase Container. Such objects don't declare their needs, but still have to be initialized before they can be used.

The initializer method takes the key of object to initialize and a $callable that will initialize the object. The callable will receive 2 arguments, the value of the object being looked up from the Container and the container itself.

For object and singleton item types initialization happens on first lookup only. While factory item types will have their initializers run every time a new instance is looked up from the Container.

The code below stores a Currency object in the container. An initializer is added for this object that ensures that a formatter is set on this object every time it is instantiated.

Packagers

Packagers are convenience helpers for grouping the dependencies of a feature as a unit. For instance if an Options features is comprised of the classes, OptionsStore, OptionsPage and OptionsValidator you would need to declare this dependencies on the container each time you need to use said Options feature.

Using a Packager object allows you to add these dependencies to the container. A packager should setup the dependencies in it's onInject function as shown below,

Now when you need the feature you only need to add the packager to the container.

The packager itself will be registered with the container as a singleton, and can be looked up by it's key.

Nested Containers

Containers can also be nested within other containers. This allows grouping dependencies within different contexts of your application. When looking up keys, parent containers are queried when a key is not found in a child container.

Here the child will use CustomWorker for resolving worker. While the logger will be looked up from the parent container.

Public Properties

For each declared need, Encase will create corresponding public properties on the object injected. A container property is also injected into the class for looking up other dependencies at runtime.

Lifecycle

An onInject event hook is provided to container items after their dependencies are injected. Any post injection initialization can be carried out here.

Testing

Encase simplifies testability of objects. Since objects are stored in the container you can reach deep inside an object's dependency graph and swap out an expensive dependency with a dummy one.

In the earlier example in order to test that the logger is indeed called by the worker we can register the worker as a mock object. Then verify that this mock was called appropriately.

Installation

Add this line to your composer.json.

And then execute:

$ composer install

System Requirements

Encase has been tested to work on these platforms.

Contributing

See contributing guidelines for Portkey.

License

MIT License. Copyright © 2014 Darshan Sawardekar


All versions of encase-php with dependencies

PHP Build Version
Package Version
No informations.
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 dsawardekar/encase-php contains the following files

Loading the files please wait ....