Category: First Page

The Horde Vfs is an abstraction around storing and retrieving files. Calling code does not care about where the Vfs is actually stored, be it a remote filesystem, a dav resource, a database or a path in the local filesystem. Autowiring means the Injector knows how to create a class using some other class without having it explicitly defined

For this article, I want to get an instance of Horde\MyApp\ReportGenerator which uses the VFS to store reports.

First let’s create the ReportGenerator.

lib/ReportGenerator.php

<php
namespace Horde\MyApp;
class ReportGenerator
{
    private $driver;
     public function __construct(\Horde_Vfs_Base $driver
     {
         $this--->driver = $driver;
     }
     ...
}


When a controller in the app wants a report generator, it would require it through the dependency injector like this:


$reportGenerator = $injector->getInstance('Horde\MyApp\ReportGenerator');


Autowiring allows the injector to return an instance even if it has not been explicitly bound to the injector. For this to work, all required dependencies must be interfaces which have either been registered with the injector or can themselves be created from registered interfaces or have no dependencies themselves.

Now, Horde_Vfs_Base is the common base class of all Horde Vfs drivers.

However, Horde does not provide a default binding for Horde_Vfs_Base even though Horde_Core has a default factory Horde_Core_Factory_Vfs.

Thus, we need to define one. In Application.php, look for a method _bootstrap(). We will use it to setup the injector binding. Normally, we would just want to use the existing factory through $injector->bindFactory($interface, $factory, $method);

We cannot do this in this case. The Vfs Factory’s create method has two string parameters to allow creating multiple Vfs instances. For our app, we just want to get the default configured in horde base. But this doesn’t work. bindFactory would automatically pass a child injector to the create method. This would override the default first parameter “horde”. In the end, we would receive the factory’s exception saying we should configure a backend first – even if we did.

To work around this, we could create an own factory class in our app which uses Horde_Core_Factory_Vfs as a dependency. Horde_Injector would just know what to do. But let’s not do this as it’s quite some boilerplate just for creating a Vfs with default configuration.

Instead, let’s use the closure binder.


protected function _bootstrap()
{
     $injector = $GLOBALS['injector'];
     $vfsClosure = function(\Horde_Injector $injector) {
     return $injector->getInstance('Horde_Core_Factory_Vfs')->create();
};
$injector->bindClosure('Horde_Vfs_Base', $vfsClosure);


Now injector knows how to provide a Horde_Vfs_Base implementation which the ReportGenerator requires. We can ask injector to provide an instance. Injector will look if it already has an instance from a previous call, otherwise runs the closure to create the dependency, then create the actual ReportGenerator instance.

In early 2019 I first wrote a few lines on migrating horde to composer based setups.

Even though I was too occupied with other business for several months, I have something to show and it is time to review what we have and what we don’t have.

The good news is, it really runs as far as I am concerned. For the mainstream apps, the Web UI works correctly as well as caldav/carddav access, handling of db schema migrations, some critical commandline scripts. There is still a lot of scripts to check and possibly fix.

The Horde Components helper has been modified to be run as a part of a horde deployment or standalone. It can also still be run from git-tools. I added some code to git-tools to improve the way it wraps horde-components. However, most things git-tools provides are no longer that interesting to the casual developer or to deploying horde master tree installations.

I also improved the horde Controller/Routes core. It is now more successful in detecting which app handles a request. Also, a new option for unauthenticated routes and for “API style” auth handling has been included. This enables REST interfaces.

I finally did a small proof of concept app which is completely based on the controller/routes core and does not have a single traditional “page” file. Maybe this should be provided as an alternative skeleton.

How to run your own composer based install

Running a new horde install for development or CI purpose is as easy as:

cd your/web/root/
git clone https://github.com/maintaina-com/horde-deployment.git .
composer install
cp web/horde/config/conf.php.dist web/horde/config/conf.php

For using a database, provide a config with a db backend instead.
You might also want to run web/horde/bin/horde-db-migrate.

I intend to improve the installer a little to detect if pre-made configs have been put into expected locations of the deployment and use them.

Why you should not use this in production

This deployment comes “as is”. It is still dependent on a satis server not controlled by the horde organisation, running a no-warranties fork of the unreleased git master code. If you run this in production, you need to do a lot of QA for your specific use case. Patches welcome. You may also encounter features not part of official horde releases because they are incomplete, lacking tests or else.

I am still trying to get this upstream. Dealing with a downsteam horde distribution of 150+ repos is tedious work. I’d rather invest time in actual software development. In case you really need to, contact me about commercial support options.

I held “12 megalis 20 mg Gründe, warum dein Patch immer abgelehnt wird” (12 top reasons why upstream rejects your patches) at Chemnitzer Linuxtage 2018, using examples from OpenStack, Horde and nextcloud. I intend to follow up with some blog posts shortly.

Boneyard – a barebone horde “dynamic view” app based on “skeleton”.

In this article, I will show you some minimal setup for a “horde5 dynamic view” application as demonstrated by hermes time tracking and kronolith calendar

Pre-requisite
We have a working git checkout of a 5.2 or master installation of horde with some authentication and prefs backend working and the migrations inplace.
If your setup did not involve editing install_dev.conf, you probably have something else and I cannot guarantee this walkthrough will work for you without adopting some parts.

Let’s generate a fresh application called boneyard

maintaina:/srv/git/horde5-webmail/horde # php framework/bin/horde-generate-module boneyard "Ralf Lang "
Started new Module in /srv/git/horde5-webmail/horde/boneyard!
Register the new Module with a file in the config/registry.d directory:

<?php
$this->applications['boneyard'] = array('name' => _("Boneyard"));


We put a file with this oneliner into the directory as advised

maintaina:/srv/git/horde5-webmail/horde # vim horde/config/registry.d/boneyard.php

Now let’s re-run the script generating the links for the git checkout installation

maintaina:/srv/git/horde5-webmail/horde # php framework/bin/install_dev
EMPTYING old web directory /srv/www/vhosts.d/horde.ralf-lang.de

[ INFO ] Package(s) to install: ALL (129 packages)
[ INFO ] Installing package ActiveSync
[.. snip ..]
[ INFO ] Installing package xxhash


Now boneyard is set up in your web-accessible dir.
Let’s make the config dir web-writeable

chown wwwrun:www /srv/www/vhosts.d/horde.ralf-lang.de/boneyard/config

This is for SUSE – debian or redhat may have different user/group for the web server.

Next go to $yourdomain/admin/config/ the admin panel and generate the conf.php file by clicking on the “boneyard” entry and then the “create boneyard config” button.
At this point, we do not care about the actual contents of this config – the defaults are just fine.

If you only see “horde” and some library names, you most probably have not edited registry.local.php to contain something like:


<?php
// By default, applications are assumed to live within the base Horde
// directory (e.g. their fileroot/webroot will be automatically determined
// by appending the application name to Horde's 'fileroot'/'webroot' setting.
// If your applications live in a different base directory, defining these
// variables will change the default directory without the need to change
// every application's 'fileroot'/'webroot' settings.
$app_fileroot = '/srv/www/vhosts.d/horde.ralf-lang.de/';

Now “Boneyard” should appear in your horde topbar with some bogus buttons and content

Let’s create the structure of a “dynamic” application

* lib/Ajax.php – The Boneyard Ajax base class to load locale- and setting-dependent content into the browser’s javascript
* lib/Ajax/Application/Handler/Example.php – A handler for Ajax requests to load data from the server — we skip that for now
* lib/View/Sidebar.php – Boneyard_View_Sidebar – a sidebar for the dynamic view
* template/dynamic/sidebar.html.php – The template used by the sidebar view
* template/dynamic/index.inc – The main template of the dynamic view
* template/dynamic/example1.inc – One of our two example views in this demo
* template/dynamic/example2.inc – One of our two example views in this demo
* js/boneyard.js – The BoneyardCore object which contains the main click handler etc

We also need to touch the index.php file to enable the dynamic view and the lib/Application.php file to advertise that dynamic view exists.

See https://github.com/ralflang/horde-boneyard to view the code in detail.