Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>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).</p> <p>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.</p> <p>Further, I understand conventions for class naming and file locations that enable easy autoloading. Ex: <code>class App_Model_User</code> resides in a folder <code>App/Model/User.php</code></p> <p>I think what can be potentially confusing is that in the script context, where you have not yet</p> <ul> <li>done the .htaccess magic that pushes all request to <code>public/index.php</code></li> <li>set your <code>APPLICATION_PATH</code> and include paths in <code>public/index.php</code></li> <li>created your <code>Application</code> or <code>Bootstrap</code> object tied to a config file</li> </ul> <p>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.</p> <p>I guess my answer to the original question would be that the usual entry point sequence of </p> <p>http request -> .htaccess -> index.php -> config</p> <p>sets up much of our environment for us, we would need to duplicate some of that for different entry path.</p> <p>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. </p> <p>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 <code>$application->run();</code> 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.</p> <p>But here I confess to being less confident and just throwing out ideas.</p> <p>Hope all this helps someone. It actually helped me to write it all down. Thanks and cheers!</p> <p><strong>Update 2009-09-29:</strong> Just ran across this article: <a href="http://webfractor.wordpress.com/2008/08/14/using-zend-framework-from-the-command-line/" rel="nofollow noreferrer">Using Zend Framework from the Command Line</a></p> <p><strong>Update 2009-11-20:</strong> And another article: <a href="http://www.gsdesign.ro/blog/cron-jobs-in-zend-framework/" rel="nofollow noreferrer">Cron jobs in Zend Framework | GS Design</a></p> <p><strong>Update 2010-02-25:</strong> <a href="http://www.davidcaunt.co.uk/2010/02/25/easy-command-line-scripts-with-zend-application/" rel="nofollow noreferrer">Easy command line scripts with Zend Application - David Caunt</a></p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload