Skip to content
Jim Martens edited this page Feb 24, 2015 · 12 revisions

Cleared for editing

This page has the goal to collect ideas about the architecture and specific functionality of the package system. In specific it is important to know how a package is structured (e.g. XML files, source files) and how such a package is installed.

Package Structure

There is no classical package structure. A 'package' is basically just an entry in an XML file with some meta information including but not limited to composer-relevant info, description, license.

The system gets this information with a monitored XML file that only contains tested and approved packages.

Package Installation

Virtual bundle

The distribution will work as a virtual bundle that requires all installed packages. That way we can use Composer even though it can only handle requirements.

Installation steps

User

In the following you will see the steps for the installation (user perspective).

  1. Search for package
  2. Click on install
  3. Package requirements check
  4. Download the package
  5. Performing the installation
  6. Fire successful installation event
  7. Finish installation and show success message to admin
  8. Optional packages offer (packages can offer recommended/optional packages, here you can select them for installation)
  9. Optional: Rate installation experience and give your opinion (will be used to improve the product)

Step 8 might not be implemented as it could require an own dependency management which will be avoided.

Technical

  1. Download the bundle
  2. Adding the bundle to the requirements of the virtual bundle
  3. Install bundle (composer)
  4. Adding the bundle to the plugin directory
  5. Finish the installation

Dependency management

The system doesn't use it's own dependency management. Instead it will use Composer for that purpose.

Plugin directory

To circumvent the problematic alteration of the AppKernel file, it will be modified in the web-platform-edition to dynamically include additional bundles. For that purpose it will search through a plugin directory which contains an index file and various definition files that begin with a numeric index. The index file contains the highest not yet used integer and will be updated whenever a new bundle file is added into the directory.

The integer from the index file is taken to form the new filename. It starts with the integer, followed by an underscore, followed by the Composer identifier of the bundle. The slash is translated to an underscore.

The default contents of this plugin directory are the bundles that are shipped with the 2martens Web Platform Edition and by default enabled.

This way is the cleanest one to achieve our goals. The downside is that you MUST use the 2martens Web Platform Edition to use the automatic bundle registration. In the Symfony Standard Edition (with the Web Platform installed) you can install packages from ACP. but they won't be loaded upon the next request. You have to manually edit the AppKernel file to register them.

Technical structure of installation process

The installation process contains several areas. The first area contains predefined forms and pages before the actual installation. Next is the installation via Composer. Last is a phase which shows predefined forms and pages again.

Package servers

There will be one official package server that provides an XML file with all approved packages. To add a package here, a formal addition process will be developed. For this process a package.xml will be used. The information of this file will be added to the package server xml on approval. Admins can search the available packages through the ACP.