Intégration de scripts externes avec Zend Framework

Question

Quel est le meilleur moyen d'intégrer un script externe dans Zend Framework? Laissez-moi vous expliquer parce que je pose peut-être la question de la mauvaise façon. J'ai un script qui télécharge et analyse un fichier XML. Ce script, qui s'exécute sous la forme d'un travail cron quotidien, doit sauvegarder ses données dans la base de données. J'utilise Zend Framework pour le site qui utilise ce script et il me semble qu'il serait préférable d'utiliser mon modèle sous-classé de Zend_Db_Abstract pour faire l'ajout et la mise à jour de la base de données. Comment va-t-on faire ça? Est-ce que mon script va dans la bibliothèque à côté des composants Zend (c'est-à-dire library/Mine/Xmlparse.php) et a donc accès aux différents composants ZF? Dois-je simplement inclure les fichiers de modèle corrects et le composant Zend DB dans le fichier lui-même? Quelle est la meilleure façon de gérer ce type d'intégration?

Answer 1

Dans votre répertoire de bibliothèque, vous devez disposer de votre propre bibliothèque à côté du dossier de la bibliothèque Zend. Tout ce que vous appelez (myLib, projet, ...) vous devez inclure dans le autochargeur Zend et qui est fait comme suit:

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

Pour votre bibliothèque d'intégrer bien avec ZF et la autochargeur vous devriez coller aux conventions de nommage ZF.Cela signifie deux choses:

• si vous étendez une classe de ZF existante, reproduire la structure du dossier ZF afin que votre fichier a le même chemin et le nom à l'exception du nom de la bibliothèque. Par exemple. /library/Zend/Db/Abstract.php => /library/Project/Db/Abstract.php.
• Si vous écrivez vos propres classes, respectez toujours les conventions de dénomination ZF de l'autochargeur pour les trouver.

Answer 2

Je suis juste tombé sur quelque chose qui pourrait être pertinent à cette question. L'auteur recommande simplement de créer un dossier de scripts dans la hiérarchie ZF et de l'utiliser normalement comme dans ZF (bien qu'il définisse le chemin ini et appelle le chargement automatique). Est-ce si simple? Est-ce que le simple fait d'être dans la hiérarchie du framework et d'inclure le chemin et le chargeur automatique permet à votre script d'accéder à tous les goodies?

Answer 3

Je ne suis pas sûr à 100% de ce que vous essayez de demander mais je vais essayer de vous aider. Si, à un moment donné, vous ajoutez une référence à "/ path/to/zend/framework" dans votre chemin d'inclusion php, vous avez activé le Zend Framework. De là, si vous le faites:

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

Puis, à tout moment dans votre script, vous pouvez à peu près juste de créer de nouveaux objets Zend Framework et Zend_Loader se chargera du reste. L'une des grandes choses à propos de Zend Framework n'est pas de vous forcer à faire les choses d'une certaine manière. C'est pourquoi parfois il y a plusieurs façons d'accomplir la même chose. Donc, si vous pensez que vous avez besoin de faire votre script utiliser le Zend Framework juste pour le faire, ce n'est pas vraiment nécessaire. Mais si vous pensez que cela peut améliorer votre script, alors allez-y.

Answer 4

Je place généralement des choses personnalisées qui pourraient être utilisées dans plusieurs projets dans un dossier personnalisé de la bibliothèque. J'ai donc une bibliothèque/dossier Ak33m qui a des scripts qui peuvent être en dehors du cadre.

Answer 5

Oui, vous devez placer vos propres classes qui héritent peut-être des classes Zend Framework ou ajouter d'autres classes dans votre propre dossier à côté du dossier Zend Framework dans la bibliothèque.

Lorsque vous avez le chargement automatique de Zend_Loader activé, les noms de classe assignera automatiquement la classe que vous avez créé, par exemple:

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

Answer 6

En tant que ZF noob moi-même, je pense que je comprends certains de ce que l'OP essaie de comprendre. Donc, je vais juste expliquer un peu de ce que je comprends dans l'espoir qu'il soit utile à l'OP (ou plus probablement, à un futur lecteur, puisque la question originale est si vieille et j'imagine que OP est maintenant un ZF gourou).

Je comprends que ZF prétend être en grande partie « utiliser à volonté », de sorte que vous devez pas acheter dans une structure entière, comme le Zend_Application, la classe Zend_Bootstrap, toute approche MVC, etc.

En outre, Je comprends les conventions pour les noms de classe et les emplacements de fichiers qui facilitent le chargement automatique.Ex: class App_Model_User réside dans un dossier App/Model/User.php

Je pense que ce qui peut être potentiellement source de confusion est que dans le contexte de script, où vous avez pas encore

• fait la magie .htaccess qui pousse toute demande à public/index.php
• définir vos APPLICATION_PATH et incluent des chemins dans public/index.php
• créé votre Application ou Bootstrap objet lié à un fichier de configuration

Il peut être un peu difficile de savoir comment mieux se prévaloir de la plupart des qualités ZF que nous obtenons dans ce contexte et que nous voulons dans un autre contexte.

Je crois que ma réponse à la question initiale serait que la séquence de point d'entrée habituelle de

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

met en place une grande partie de notre environnement pour nous, nous aurions besoin de dupliquer une partie de cela pour un chemin d'accès différent. Donc, pour votre script, mon premier instinct serait de créer un fichier include commun qui reflète une grande partie de ce qui se passe dans index.php - définir les chemins d'inclusion, le APPLICATION_PATH, instancie et appelle un bootstrap, puis fait votre traitement spécifique au script.

Encore mieux, il peut être souhaitable de créer un point d'entrée unique pour tous vos scripts, comme nous le faisons dans le contexte http/web. Etendez Zend_Application à vos propres fins de script afin que $application->run(); ne démarre plus le traitement du routeur-contrôleur-dispatch MVC, mais effectue plutôt vos propres tâches. De cette façon, ce seul point d'entrée de script semble presque identique au point d'entrée Web, la seule différence étant l'objet d'application qui est instancié. Passez ensuite le nom de la classe Application souhaitée en tant que paramètre de ligne de commande au script.

Mais ici j'avoue être moins confiant et juste jeter des idées.

Espérons que tout cela aide quelqu'un. Cela m'a vraiment aidé à tout écrire. Merci et à bientôt!

Mise à jour 2009-09-29: Juste couru à travers cet article: Using Zend Framework from the Command Line

Mise à jour 2009-11-20: Et un autre article: Cron jobs in Zend Framework | GS Design

Mise à jour 2010-02-25:Easy command line scripts with Zend Application - David Caunt