Re: [zeta-dev] Autoloads and autoload file

2010-11-24 Thread Henri Bergius
Hi,

On Wed, Nov 24, 2010 at 10:44 AM, Maxime Thomas maxime.t...@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.berg...@gmail.com
Microblog: http://www.qaiku.com/home/bergie/


Re: [zeta-dev] Autoloads and autoload file

2010-11-24 Thread Ole Marius Smestad

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



Re: [zeta-dev] Autoloads and autoload file

2010-11-24 Thread Henri Bergius
On Wed, Nov 24, 2010 at 11:43 AM, Ole Marius Smestad o...@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.berg...@gmail.com
Microblog: http://www.qaiku.com/home/bergie/


Re: [zeta-dev] Autoloads and autoload file

2010-11-24 Thread Maxime Thomas
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 ber...@apache.org

 On Wed, Nov 24, 2010 at 11:43 AM, Ole Marius Smestad o...@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.berg...@gmail.com
 Microblog: http://www.qaiku.com/home/bergie/