You are viewing a plain text version of this content. The canonical link for it is here.
Posted to zeta-dev@incubator.apache.org by Maxime Thomas <ma...@gmail.com> on 2010/11/24 08:44:33 UTC

[zeta-dev] Autoloads and autoload file

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 real script that will get the whole mapping class/file for you.
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.
Is it the optimal solution ? Can we find a better way to link classes and
files ?

Max



[1]
http://ezcomponents.org/docs/tutorials/Base#adding-class-repositories-located-outside-ez-components-to-autoload-system

[2]
James Pic shared autoload script :

#!/bin/sh

scanPath="."
if [[ $1 != "" ]]; then
   scanPath=$1;
fi;

echo "<?php";
echo "return array(";
echo `find -L $scanPath -name "*php"  | xargs grep "^class " | sed -e
"s@\([^:]*\):class \([^ ]*\).*@    '\2' => '\1',\
@"`;
echo `find -L $scanPath -name "*php"  | xargs grep "^abstract class "
| sed -e "s@\([^:]*\):abstract class \([^ ]*\).*@    '\2' => '\1',\
@"`;
echo `find -L $scanPath -name "*php"  | xargs grep "^interface " | sed
-e "s@\([^:]*\):interface \([^ ]*\).*@    '\2' => '\1',\
@"`;
echo ");";
echo "?>";

Re: [zeta-dev] Autoloads and autoload file

Posted by Henri Bergius <be...@apache.org>.
Hi,

On Wed, Nov 24, 2010 at 10:44 AM, Maxime Thomas <ma...@gmail.com> 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 get PHP classes coming from
native packages and PHP classes coming from PEAR packages jumbled
together in /usr/share. If we want to be compliant with their policy
then a normal deployment would have multiple roots, for example like:

/usr/share/php/ZetaComponents
/usr/share/php/MidgardMVC
/usr/local/share/php/MyCoolApp

> Max

/Henri

-- 
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/

Skype: henribergius
Jabber: henri.bergius@gmail.com
Microblog: http://www.qaiku.com/home/bergie/

Re: [zeta-dev] Autoloads and autoload file

Posted by Maxime Thomas <ma...@gmail.com>.
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 whole environment
(if I correctly get it) and to follow a policy such as Debian's.

I guess PHP is still the best option for this, but I cannot find a link
between the files and the classes (as packages in Java) that can easily do
the trick.
If we can do that, and that's my next idea, we can purpose some easy
extension mechanism using PHP's Reflection or replacing it, following our
needs.

Max


2010/11/24 Henri Bergius <be...@apache.org>

> On Wed, Nov 24, 2010 at 11:43 AM, Ole Marius Smestad <om...@ez.no> 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:
>
> * Production: Zeta Components and other classes coming from PEAR or
> native packages (I'd love to see Zeta in Debian as soon as there is an
> official Apache release)
> * Development: Zeta Components and other classes coming from various
> Git/SVN checkouts
>
> The paths are likely to be quite different in these two scenarios.
>
> For production setups the relevant Debian policies are quite
> interesting. I recently packaged OpenPSA (a Midgard-based business
> management suite) to Debian and the policies made things quite clear:
> http://webapps-common.alioth.debian.org/draft-php/html/
> http://webapps-common.alioth.debian.org/draft/html/
>
> > Ole Marius
>
> /Henri
>
> --
> Henri Bergius
> Motorcycle Adventures and Free Software
> http://bergie.iki.fi/
>
> Skype: henribergius
> Jabber: henri.bergius@gmail.com
> Microblog: http://www.qaiku.com/home/bergie/
>

Re: [zeta-dev] Autoloads and autoload file

Posted by Henri Bergius <be...@apache.org>.
On Wed, Nov 24, 2010 at 11:43 AM, Ole Marius Smestad <om...@ez.no> 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:

* Production: Zeta Components and other classes coming from PEAR or
native packages (I'd love to see Zeta in Debian as soon as there is an
official Apache release)
* Development: Zeta Components and other classes coming from various
Git/SVN checkouts

The paths are likely to be quite different in these two scenarios.

For production setups the relevant Debian policies are quite
interesting. I recently packaged OpenPSA (a Midgard-based business
management suite) to Debian and the policies made things quite clear:
http://webapps-common.alioth.debian.org/draft-php/html/
http://webapps-common.alioth.debian.org/draft/html/

> Ole Marius

/Henri

-- 
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/

Skype: henribergius
Jabber: henri.bergius@gmail.com
Microblog: http://www.qaiku.com/home/bergie/

Re: [zeta-dev] Autoloads and autoload file

Posted by Ole Marius Smestad <om...@ez.no>.
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 been toying with the idea of adopting the scripts to also create a similar list, which could work with components.

-- 
Regards,
Ole Marius