Actually, I was thinking about this autoloads script for an app as it's done
with eZP. It could be part of the ezcBase as an independent script.
My point was to challenge the ezpublish strategy and see how to integrate it
into ezcBase.
By the way, I understand the point to normalize that for a whol
On Wed, Nov 24, 2010 at 11:43 AM, Ole Marius Smestad wrote:
> For production environments it makes sense, and we have been toying with the
> idea of adopting the scripts to also create a similar list,
> which could work with components.
In regular situations you probably need two setups:
* Prod
On 24. nov. 2010, at 09.44, Maxime Thomas wrote:
[…]
> I've checked in ez how is done the ezpautoloads script that does the job and
> the strategy is the following : list all php files, tokenize it, extract
> class names and make the file.
For production environments it makes sense, and we have
Hi,
On Wed, Nov 24, 2010 at 10:44 AM, Maxime Thomas wrote:
> I've got a small reflexion about the base mechanism of ezcBase that allows
> us to add an outside repository of classes [1].
Sounds like a good idea. A common complaint about PEAR packaging from
for example Debian Policy is that you ge
Hi there,
I've got a small reflexion about the base mechanism of ezcBase that allows
us to add an outside repository of classes [1].
Actually, I manage manually my autoload file and as we discussed before with
James Pic [2], it could be a good point to have an extend to this mechanism
and get a re