On 21. feb.. 2008, at 14.52, Thomas Koch wrote:
> Hi,
>
> I just found the two files
> trunk/doc/features/4.0/autoload.txt and
> trunk/bin/php/ezpgenerateautoloads.php
>
> in the eZP SVN checkout. The doc file says, that
> ezproot/autoload/ezp_autoload.php
./autoload/ezp_extension.php
> should be used for extensions.
>
> I see two problems with the described approach:
>
> * I have to change files in the ezproot when installing / uninstalling
> extensions. I'm sure, that there are many setups of eZP, where all
> developing is done in extensions and the ezproot can't be changed
> at all.
I see your point here. At the time we felt the current approach was
ok, but it is something we are considering to revise.
> * The script to generate autoloads includes only extensions that are
> activated. What am I supposed to do, if I activate different
> extensions for
> different siteaccesses? Or if I even dare to have equal classnames
> in
> different extensions for different clients. (Not nice, but happens.)
To be accurate, the autoload generation script will include all
extensions in the extension folder, unless specifically excluded with
the parameter on the command-line. The extension interface from the
administration interface will operate as you describe, only including
active extensions.
As for the case with different extensions for different siteaccesses,
that is indeed an issue at the moment.
Let me also give a bit of history on the current approach. During the
development phase of eZP 4.0 we wanted users to be able to run eZP out
of the box, with the default extensions, without the need to have eZ
Components installed, thus we didn't use ezcBase::addClassRepository,
right from the start. It does not mean that we don't want to improve
this in the future.
Another point, is that we would have preferred to have class prefixes
before incorporating Base's class repositories. Note, about equal
class names, when using ezcBase, the first defined class name will be
used, it will ignore the new class, if you try to load it more than
once. However, with the current code base in eZP, the latter defined
class will be used.
> May I propose an alternative?
Of course you may, and it is much appreciated :-)
> Every extension, which wants to make use of autoload, should contain
> an
> autoload directory, while leaving the autoloads (with s) directory
> untouched.
>
> The following code gives should be executed for every scriptrun and
> automatically registers all autoload dirs to ezcBase:
>
> $dirs = glob(
> 'extension/{'
> .implode( eZExtension::activeExtensions(), ',' )
> .'}/autoload',
> GLOB_BRACE | GLOB_ONLYDIR | GLOB_NOSORT
> );
>
> foreach( $dirs as $dir )
> {
> ezcBase::addClassRepository(
> substr( $dir, 0, -9 ),
> $dir
> );
> }
Thanks for your proposal Thomas, we will keep this list updated as
well as the website, to future updates on the autoload front.
--
Best regards,
Ole Marius
--
Sdk-public mailing list
[email protected]
http://lists.ez.no/mailman/listinfo/sdk-public
