On 03/09/16 16:43, Rowan Collins wrote:
>> This is perhaps my sticking point. I have a perfectly stable framework
>> without the need for any 'autoloader', and a folder structure that
>> works. Reworking the whole framework so that it follows the 'vendor'
>> rules while still also just working with bog standard require_once in
>> the right place is where I keep coming unstuck.
>
> Right, I remember switching to using an autoloader (long long before
> composer existed), and what a relief it was not to have to manage great
> lists of require_once everywhere any more. :) I think the only thing we
> had to fix was some class names being used as lower-case, when the
> filenames that needed including were camel-case. The simplest migration
> that occurs to me is "if ( file_exists('vendor/autoload.php') ) {
> require_once 'vendor/autoload.php'; } else { /* require all the
> individual dependencies as before */ }".
The problem with that 'simple migration' is that currently I have
nothing in the 'vendor/autoload.php' pot and everything in the
'individual dependencies'. I don't recognise the 'manage great lists of
require_once everywhere' simply replacing 'vendor/autoload.php' with
'../kernel/setup_inc.php' to load the framework. Yes the framework is
something of a maze of functions and files, but it only loads a class
when it needs it, and skips those it does not need. 15+ years of
development starting back in PHP4 days. It's reworking 50+ major
packages, pulling out the few files that make up the classes and
repackaging them in 'vendor' format, while still having smarty plugins,
templates, modules, admin tools and the like and managing just what
tools a user has access to based on their role when accessing the site.
In essence the composer setup is user specific if I am going down that
path, and while making everything available and then not allowing access
may be the modern way, only loading the sub-set of packages that the
current job needs seems a lot faster to me. And if the user does not
have access rights at all we only get as far as loading the access
control functions, and throw an error page back.
I do have a few third party elements. Smarty is now 'composer loadable',
but ADOdb is not and has it's own db selected loader. But smarty is
extended with additional local plug-ins so I don't see how there is any
gain moving files around the file system rather than keeping them with
their intended package. And returning to PEAR, if the relevant package
is available, those functions are also switched on, or one falls back to
defaults. The installer advises what it can and can't find, gives
guidance to installing required tools and advise on optional ones.
Something that is easy to do with the PEAR/PECL/dynamic extension system
we currently have, but not so easy to manage with composer? A handler
can obviously be written to edit the composer setup on the fly, and it's
that sort of support I would expect if composer replaces PEAR.
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
