Integrating external scripts with Zend Framework

Question

What is the best way to integrate an external script into the Zend Framework? Let me explain because I may be asking this the wrong way. I have a script that downloads and parses an XML file. This script, which runs as a daily cron job, needs to dump its data into the database.

I am using Zend Framework for the site which uses this script and it seems to me that it would be best to use my subclassed model of Zend_Db_Abstract to do the adding and updating of the database. How does one go about doing this? Does my script go in the library next to the Zend Components (i.e. library/Mine/Xmlparse.php) and thus have access to the various ZF components? Do I simply need to include the correct model files and the Zend DB component in the file itself? What is the best way to handle this sort of integration?

Answer 1

Yes, you should put your own classes that maybe inherit Zend Framework classes or add further classes into your own folder next to the Zend Framework folder in library.

When you have Zend_Loader s auto-loading enabled, the class names will automatically map to the class you created, e.g.:

My_Db_Abstract will map to My/Db/Abstract.php .

Answer 2

In your library directory you should have your own library next to the Zend library folder. Whatever you call it (Mylib, Project, ...) you should include it into the Zend Autoloader and that's done as follows:

require_once 'Zend/Loader/Autoloader.php';
$loader = Zend_Loader_Autoloader::getInstance();
$loader->registerNamespace('Project_');
$loader->setFallbackAutoloader(true);
if ($configSection == 'development')
{
    $loader->suppressNotFoundWarnings(false);
}

In order for you library to integrate nicely with ZF and the Autoloader you should stick to the ZF naming conventions. This means two things:

• if you extend an existing ZF class, replicate the ZF folder structure so that your file has the same path and name except for the library name. E.g. /library/Zend/Db/Abstract.php => /library/Project/Db/Abstract.php.
• if you write your own classes, still stick to the ZF naming conventions for the autoloader to find them.

Answer 3

I usually put custom stuff that I think could be used across projects in a custom folder in the library. So I have a library/Ak33m folder that has scripts that may be outside of the framework.

Answer 4

As a ZF noob myself, I think I understand some of what the OP is trying to figure out. So, I'll just explain a bit of what I understand in the hope that it is helpful either to the OP (or more likely, to a future reader, since the original question is so old and I imagine that OP is now a ZF guru).

I understand that ZF claims to be largely "use at will", so that you need no buy into an entire structure, like the Zend_Application, the Zend_Bootstrap class, the entire MVC approach, etc.

Further, I understand conventions for class naming and file locations that enable easy autoloading. Ex: class App_Model_User resides in a folder App/Model/User.php

I think what can be potentially confusing is that in the script context, where you have not yet

• done the .htaccess magic that pushes all request to public/index.php
• set your APPLICATION_PATH and include paths in public/index.php
• created your Application or Bootstrap object tied to a config file

it can be a little bit unclear how best to avail yourself of most of the ZF goodness we get in that context and want in another context.

I guess my answer to the original question would be that the usual entry point sequence of

http request -> .htaccess -> index.php -> config

sets up much of our environment for us, we would need to duplicate some of that for different entry path.

So, for your script, my first instinct would be to create a common include file that mirrors much of what happens in index.php - set the include paths, the APPLICATION_PATH, instantiates and calls a bootstrap, and then does your script-specific processing.

Even better, it might be desirable to create a single entry point for all your scripts, like we do in the http/web context. Extend Zend_Application for your own script purposes so that $application->run(); no longer starts up the MVC router-controller-dispatch processing, but rather does your own stuff. In that way, this single script entry point would look almost identical to the web entry point, the only difference being which application object gets instantiated. Then pass the name of your desired Application class as a command line parameter to the script.

But here I confess to being less confident and just throwing out ideas.

Hope all this helps someone. It actually helped me to write it all down. Thanks and cheers!

Update 2009-09-29: Just ran across this article: Using Zend Framework from the Command Line

Update 2009-11-20: And another article: Cron jobs in Zend Framework | GS Design

Update 2010-02-25: Easy command line scripts with Zend Application - David Caunt

Answer 5

I just came across something that may be germane to this question. This IBM developerWorks article.

The author recommends simply creating a scripts folder in the ZF hierarchy and the using it as one normally would within ZF (though he does set the ini path and call autoload). Is it that simple? Does simply being in the hierarchy of the framework and including the path and autoloader grant your script access to all of the goodies?

Answer 6

I'm not 100% sure what you're trying to ask but I will try to help. If at any point you add a reference to "/path/to/zend/framework" into your php include path then you have in essence enabled the Zend Framework. From there if you do:

require_once('Zend/Loader.php');
Zend_Loader::registerAutoload();

Then at any point in your script you can pretty much just create new Zend Framework objects and Zend_Loader will handle the rest.

One of the big things about the Zend Framework though is not forcing you to do things a certain way. That's why sometimes there are several ways to accomplish the same thing. So, if you feel you need to make your script use the Zend Framework just for the sake of doing so this is not really necessary. But if you think it may improve your script in some way then go for it.