Download the PHP package webfactory/legacy-integration-bundle without Composer

On this page you can find all versions of the php package webfactory/legacy-integration-bundle. 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?

Example code of webfactory/legacy-integration-bundle

Informations about the package legacy-integration-bundle

WebfactoryLegacyIntegrationBundle

This bundle provides an approach to integrate existing legacy applications with Symfony2.

In brief, the approach is to run a particular event listener on the kernel.controller event. This event listener will decide whether and how to run the legacy application. The response generated by the legacy application will then be captured.

Later, after the Symfony2 Controller has been executed and a Twig template is being rendered, fragments of the "legacy response" can be retrieved and be used as part of the output.

That way, you can start with your legacy application and Symfony2 in coexistence next to each other. You can then incrementally start to shift functionality over to the Symfony2 stack while maintaining a coherent user experience.

Because Symfony2 is driving this process and Twig templates have the control authority of which parts of the legacy response are being used, this approach will naturally "grow" away from the legacy application towards the Symfony2 stack.

Take care: This bundle currently uses webfactory/dom, a small set of utilities on top of PHP's DOM extension, to process the legacy application's repsonse and provide XPath-based access to it. It will only work if your old application returns well-formed XHTML or Polyglot HTML5.

To learn more about this concept, its benefits and caveats, use your time-machine and visit the Symfony2 User Group Colone meeting on 2013-12-18.

Installation

Just like any other Symfony2 bundle, left as an exercise to the reader.

Configuration

The legacy "bootstrap" file

You must provide a single file that can be include()ed in order to run your legacy application. Typically you will already have this - it should be your legacy application's front controller.

If you are running PHP < 5.4, this file should return the HTTP status code sent by the legacy application. Starting with PHP 5.4, http_response_code() will be used to detect it.

Also, as this bundle will try to capture the response including headers using output buffering, you must not flush the response body or headers to the client.

Using it

Once you're set up, use the @Dispatch annotation on your controller to run the legacy application before your controller - like so:

This will run your legacy application before entering the controller. The entire output including HTTP headers (repeat after me: including HTTP headers) will be captured and saved. Nothing will be sent to the client unless you take care of doing so.

Regarding the legacy response body, there are two ways of mixing your legacy world with your new world: Either you create a new layout and embed parts of the legacy application, or you retain your old layout and embed new parts in it. The following sections explain both of them.

Regarding HTTP headers and especially cookies sent by the legacy application make sure you don't miss the filters explained further below. For example, if your legacy code uses session_start() you probably need to forward the session cookie.

Using XPath to embed parts of the legacy response in your new layout

This is the way we recommend in general. If you're doing your legacy integration for a frontend redesign or if it's not too hard to rewrite your layout in the Symfony world, you should do that.

Only with this approach you can implement new functionality on the Symfony 2 stack that can be executed without running the legacy application at all.

For the use cases that need to be run (partially) in legacy, you can use the Twig global legacyApplication provided by the bundle to access parts of the response and place it in your views.

Replacing arbitrary placeholders in the legacy response with markup generated by Twig

Sometimes you will have to focus on delivering new functionality on the Symfony 2 stack and you will be stuck with a page layout generated in the legacy application.

This has the disadvantage of having to run the legacy application on every request just to get this layout, which is a penalty performance-wise. Even completely new functionality will need to run the legacy application every time.

The two Twig functions webfactoy_legacy_integration_embed() and webfactory_legacy_integration_embed_result() help with this style of integration.

These replacements are best kept in a base layout template in Twig and mapped to Twig blocks, like so:

This layout template performs no other output than the one provided by webfactory_legacy_integration_embed_result(). It can then be extended like this:

This has the benefit of isolating the new-functionality.html.twig template from the way it is integrated with the legacy application. Once you shift the page layout over to the Symfony 2 stack, you can update the baseLayout.html.twig template (of course it should output the main_content block as well!) and stop dispatching the legacy application for the new functionality.

Filters

The LegacyApplicationDispatchingEventListener can take a set of Filters which must implement the Webfactory\Bundle\LegacyIntegrationBundle\Integration\Filter interface.

Once the legacy application has been executed, all registered filters are passed the ControllerEvent which triggered the event listener as well as the Response object that was created for the legacy application.

The primary use case for this is to be able to examine the response and choose to send it to the client as-is, bypassing execution of the Symfony2 controller. That way, you can have routes/controllers in Symfony2 to trigger (or allow) the execution of particular use-cases in your legacy application while still returning its response unmodified initially.

You can use the webfactory_legacy_integration.filter tag to add more filters. A more convenient way is the use of additional annotations as follows.

Filter annotations

The Webfactory\Bundle\LegacyIntegrationBundle\Integration\Annotation namespace contains a few annotations you can use in addition to the @Legacy\Dispatch annotation described earlier.

In particular,

Bugs

We've used this bundle successfully to slowly migrate a couple of applications and projects to the Symfony2 stack. Yet it deserves a little more love, fine-polishing, and documentation. Feel free to open PRs or open issues for it to express your interest in it.

Oh, and unit tests would be fine :)

All versions of legacy-integration-bundle with dependencies

PHP Build Version
Package Version
Requires ext-tidy Version *
doctrine/annotations Version ~1.0
psr/container Version ^1.0
psr/log Version ^1.0
symfony/config Version ^4.3|^5.0|^6.0|^7.0
symfony/dependency-injection Version ^4.3|^5.0|^6.0|^7.0
symfony/framework-bundle Version 3.4.*|^4.0|^5.0|^6.0|^7.0
symfony/http-foundation Version ^4.0|^5.0|^6.0|^7.0
symfony/http-kernel Version ^4.3|^5.0|^6.0|^7.0
symfony/service-contracts Version ^1.0|^2.0|^3.0
twig/twig Version ^1.34|^2.0|^3.0
webfactory/dom Version ~1.0, >= 1.0.15
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 webfactory/legacy-integration-bundle contains the following files

Loading the files please wait ....