basdenooijer/solarium — Issue #54: Improve the structure of Solarium
Author: basdenooijer
Created: 2011-12-21 06:57:20+00:00
State: open
Labels: Improvement

Solarium is growing bigger, and not everyone will need all parts. Some will even only want to use a small part and that should be possible. Following the trend set by for instance Symfony2 Solarium should be made into a collection of components that can also be used by themselves.

This will require some reorganizing of files. For instance, currently the code for a query type is spread over multiple folder, for instance the update query:
- Client/RequestBuilder/Update.php
- Client/ResponseParser/Update.php
- Query/Update/*
- Result/Update.php
And the update query is one of the simplest examples, the select query for instance involves a lot more files. Ideally this would all be reorganized into Query/Update/*

By doing so a query becomes a component that can be used standalone. If you for instance already have a Solr implementation and only want to replace a query string builder with the Solarium query API you can do so with a single component, instead of needing the whole library.

Shared functionality can be placed in a special component, with dependencies managed by Composer. Maybe git subtrees can even be used.

This also fits in nicely with using components from other sources. For instance the Symfony2 EventDispatcher component.
I do not yet have experience using a component structure in a project this way, so some of my assumptions might need to be altered. Feedback is appreciated.