-- Mike A<mik...@hotmail.co.uk> wrote
(on Monday, 15 March 2010, 07:41 PM -0800):
Asking this because I've researched for a week but remain unclear. I need to
know not only for projects but to help newcomers in a book chapter currently
under authorship. Before asking I have set up a test project having access
to two modules (default and admin) with a personalised library and two ZF
libraries (ZF1.0 and ZF 1.12) in a "libraries" folder (both ZF libraries
have a subdirectory "Zend" to conform) so a quick switch between versions
can be made in the application.php which calls Zend_Application and
Bootstrap.php.
Umm... don't mean to be contradictory from the outset, but can you
clarify the version numbers you're using? ZF 1.12 does not exist, and I
fail to see why you'd be using ZF 1.0 for any examples or test projects
at this time as it's severely out-of-date.
BTW, if you're using ZF 1.10 or above, you can actually switch between
ZF versions fairly easily; see
http://framework.zend.com/manual/en/zend.loader.autoloader.html
under the heading "Selecting a Zend Framework version".
In all cases, an application.php "start up" file works fine in one
environment but will not transpose to another, especially Ubuntu (v9.10).
There are problems with autoloading unless I change the file to suit a
particular operating environment. This suggests there is something lacking
in the ZF approach to loader/autoloader methods. I mention this last point
on the basis that a stable framework should work across all intended
platforms once the environment is set up.
Honestly, I'm going to need a lot more detail than this -- full file
hierarchy, the test script in question, etc. I use Ubuntu as my primary
desktop and testing platform, and can assure you that autoloading works
fine in that environment. Additionally, we test regularly on Mac and
Windows -- the autoloader is designed to be OS-agnostic. If it's truly
not working for you, my guess is that you are not defining your
include_path well -- but without more information, I cannot verify that.
The key to good bug reporting is providing good reproduce cases. More
detail is always better -- but stick to the bare minimum of detail
needed to reproduce the issue.
I've seen lots of references, tutorials and forum posts displaying problems
with setting up a modular ZF project before asking. I recognise that servers
can be set up in different ways but surely ZF should work in a shared
hosting environment with web root (htdocs) for public access and none-public
folders for processing - and be capable of moving from one host to another
without needing to change paths if the directory structure is kept intact.
Yes it can, and yes it does. We don't recommend the practice, as it's
more secure to keep application files outside the web root -- but ZF can
and does work fine in such environments. Again, it's simply a matter of
include_path and application path configuration.
1. Is there a tutorial/reference that some kind soul somewhere can point me
to which explains setting up a ZF project in the context mentioned?
References in ZF manual are somewhat basic/raw.
It's really easy:
* Make sure your include_path includes an entry pointing to the
directory above the "Zend/" subdirectory of your ZF install.
* Make sure your APPLICATION_PATH constant points to your application/
directory, and that you specify an appropriate path to your
application configuration file when instantiating Zend_Application.
As an example, if you have the following directory layout:
web_root/
|-- application/
| |-- Bootstrap.php
| |-- configs/
| | |-- application.ini
...
|-- library/
| |-- Zend/
|-- index.php
then I'd create my index.php as follows:
<?php
// Define path to application directory
defined('APPLICATION_PATH')
|| define('APPLICATION_PATH', realpath(dirname(__FILE__) .
'/application'));
// Define application environment
defined('APPLICATION_ENV')
|| define('APPLICATION_ENV', (getenv('APPLICATION_ENV') ?
getenv('APPLICATION_ENV') : 'production'));
// Ensure library/ is on include_path
set_include_path(implode(PATH_SEPARATOR, array(
realpath(APPLICATION_PATH . '/library'),
get_include_path(),
)));
/** Zend_Application */
require_once 'Zend/Application.php';
// Create application, bootstrap, and run
$application = new Zend_Application(
APPLICATION_ENV,
APPLICATION_PATH . '/configs/application.ini'
);
$application->bootstrap()
->run();
If you look carefully, it's not much different from the
public/index.html that Zend_Tool creates -- the only real differences
are that the paths specified for APPLICATION_PATH and the include_path
do not include parent directory traversal as they're in the same
relative location as the current directory.
2. Are there plans to simplify manual set-up and autoloading processes (ie,
without using Zend Tool)? If so, references/when?
I'm really not sure what needs to be simplified. Can you elaborate on
what you feel is too complex?
3. Appreciating always that I am/was not privy to the mindset and in-house
discussions bearing upon the mode of configuring paths and choice of
autoloading, can someone briefly describe the problems/issues leading to
adopting system path methods that do not work across platforms?*
You can configure the include_path within PHP scripts -- the index.php
above does this. The only "gotchas" you need to worry about are ensuring
that the various entries are separated by the OS-specific path
separator. PHP makes this trivial by defining a PATH_SEPARATOR constant
(also used above).
4. Is ZF development currently in a phase bridging<v1.10 with forthcoming
v2.0 and thus exposing a few niggles, like that of autoloading? If so, are
there other basic areas of the framework undergoing change that will expose
cross-platform configuration issues.
First off, we're not going to bridge versions< 1.10 with 2.0. 2.0 is an
evolutionary development that will be building off current revisions,
while also introducing namespaces, lambdas, and some rewrites.
Autoloading has been common in ZF for some time; in 1.8, we made it more
"official" with the introduction of Zend_Application, which uses
autoloading by default. The only changes we anticipate to the basic
autoloading mechanism is ensuring support for PHP 5.3 namespaces as well
as 5.2-style vendor prefixes (support for 5.3 namespaces is already
available in ZF 1.10; differentiation between them and vendor prefixes
is available on the development-2.0 branch). And, of course, 2.0 will
require autoloading -- require_once statements will be gone from the
library (except in a few select cases, primarily in the Zend\Loader
tree).
As noted, autoloading currently works and is tested across platforms --
unless you can provide me with a reproduce case that proves otherwise.
