This is an initial pass on restructuring this repository in order to sanely support a git subsplit (while still supporting the current monorepo).
The files are reorganized to support 8 separate packages:
pagerfanta/core - The "core" API (base Pagerfanta class, AdapterInterface, ViewInterface and the view factory, and the views and corresponding PHP templates)
pagerfanta/doctrine-collections-adapter - The Doctrine Collection and Selectable adapters
pagerfanta/doctrine-dbal-adapter - The Doctrine DBAL adapters
pagerfanta/doctrine-mongodb-odm-adapter - The Doctrine MongoDB ODM adapter
pagerfanta/doctrine-orm-adapter - The Doctrine ORM adapter
pagerfanta/doctrine-phpcr-odm-adapter - The Doctrine PHPCR ODM adapter
pagerfanta/elastica-adapter - The Elastica adapter
pagerfanta/solarium-adapter - The Solarium adapter
As is, this creates new namespaces for all of the adapter classes with B/C for dependencies to the monolithic package, once 3.0 comes around the old class names will go away.
Purposefully, I didn't move any of the deprecated adapters. It's clearly not a lot of work to do it, and might make it easier for someone to pick up and maintain if they want to use one of them if done, but I didn't see the value personally since they're all reliant on unmaintained upstreams.
Some pros of having split packages:
Dependencies can be required (right now all adapter dependencies are required in dev only, and even that's incomplete as the MongoDB dependencies are only required in CI, and there are zero conflicts so basically every dependency has a de facto unbounded range)
Being able to add new features without forcing them on downstream users (i.e. when #5 is actioned anyone who is using the split packages wouldn't be arbitrarily forced into having Twig as a dependency or the dozen or so files installed)
Some cons of split packages:
Requires extra maintenance from me (as I'll need to keep up a system somewhere to run the splits, be it a SaaS or running splitsh-lite on one of my servers or keeping an eye on read-only repos so potential pull requests aren't ignored)
Extra dependency tracking for downstream users (well, maybe this one's 50/50; right now you install pagerfanta/pagerfanta and just use it (assuming you have the adapter dependencies already installed, which right now have zero version constraints enforced), with this you "should" install pagerfanta/core and whatever adapter(s) you need or potentially pagerfanta/twig whenever that's done)
TODO
[x] Decide where to run tests from (leave at root of monorepo only or run tests for each package separately)
[ ] Restructure docs for split package based approach
This is an initial pass on restructuring this repository in order to sanely support a git subsplit (while still supporting the current monorepo).
The files are reorganized to support 8 separate packages:
pagerfanta/core- The "core" API (basePagerfantaclass,AdapterInterface,ViewInterfaceand the view factory, and the views and corresponding PHP templates)pagerfanta/doctrine-collections-adapter- The Doctrine Collection and Selectable adapterspagerfanta/doctrine-dbal-adapter- The Doctrine DBAL adapterspagerfanta/doctrine-mongodb-odm-adapter- The Doctrine MongoDB ODM adapterpagerfanta/doctrine-orm-adapter- The Doctrine ORM adapterpagerfanta/doctrine-phpcr-odm-adapter- The Doctrine PHPCR ODM adapterpagerfanta/elastica-adapter- The Elastica adapterpagerfanta/solarium-adapter- The Solarium adapterAs is, this creates new namespaces for all of the adapter classes with B/C for dependencies to the monolithic package, once 3.0 comes around the old class names will go away.
Purposefully, I didn't move any of the deprecated adapters. It's clearly not a lot of work to do it, and might make it easier for someone to pick up and maintain if they want to use one of them if done, but I didn't see the value personally since they're all reliant on unmaintained upstreams.
Some pros of having split packages:
Some cons of split packages:
splitsh-liteon one of my servers or keeping an eye on read-only repos so potential pull requests aren't ignored)pagerfanta/pagerfantaand just use it (assuming you have the adapter dependencies already installed, which right now have zero version constraints enforced), with this you "should" installpagerfanta/coreand whatever adapter(s) you need or potentiallypagerfanta/twigwhenever that's done)TODO