Lister les fichiers d’un dossier en TypoScript

Par défaut

Petit exemple sommaire et perfectible pour liste des fichiers contenu dans un dossier en Typoscript.
L’idée ici est de lister des images pour un carrousel.

20 = TEXT
20 {
 wrap = |
 filelist = fileadmin/templates/monsite/carousel_bandeau/||name
 split {
  token = ,
  cObjNum = 1
  1 = TEXT
  1 {
   current = 1
   wrap = < img src="fileadmin/templates/monsite/carousel_bandeau/|" />
  }
 }
}

Source : http://old.nabble.com/-TYPO3-english–List-of-files-from-a-directory-with-TS-td24562172.html

Utiliser des sections à la TemplaVoilà dans une flexform

Par défaut
Il est parfois nécessaire de pouvoir saisir des éléments répétitifs au travers d’un flexform, de la même façon qu’il est possible de le faire via les FCE de TemplaVoilà.

Le FlexForm :

 

<accroche>
  <TCEforms>
    <label>Accroche</label>
    <config>
      <type>text</type>
      <cols>30</cols>
      <rows>5</rows>
    </config>
  </TCEforms>
</accroche>
<services>
  <section>1</section>
  <type>array</type>
  <el>
    <service>
      <type>array</type>
      <tx_templavoila>
        <title>Ajouter un service</title>
      </tx_templavoila>
      <el>
        <nom>
          <TCEforms>
            <label>Nom</label>
            <config>
              <type>input</type>
              <size>30</size>
            </config>
          </TCEforms>
        </nom>
        <description>
          <TCEforms>
            <label>Description</label>
            <config>
              <type>text</type>
              <cols>30</cols>
              <rows>5</rows>
            </config>
          </TCEforms>
        </description>
      </el>
    </service>
  </el>
</services>

 

La partie php (ok elle est moche et perfectible) :
&lt;?php
/**
 * Récupère les valeur du flexform
 */

function getFlexform2Array() {
 $piFlexForm = $this-&gt;cObj-&gt;data['pi_flexform'];
 foreach($piFlexForm['data'] as $sheet =&gt; $data) { 
  foreach($data as $lang =&gt; $value) { 
   foreach($value as $key =&gt; $val) {  
    if(isset($val['el']) == true) { 
     $this-&gt;lConf[$key] = $this-&gt;getFlexFormSection($val);
    } else {
     $this-&gt;lConf[$key] = $this-&gt;pi_getFFvalue($piFlexForm, $key, $sheet);
    }
   }
  }
 }
}

/**
 * Récupère les valeurs d'une section
 * @param Array Section data
 * @return Array Valeurs de la section
 */

function getFlexFormSection($sections) {
 foreach($sections['el'] as $section) {
  foreach($section as $sectionName =&gt; $sectionData) {
   if(is_array($sectionData['el'])) {
    $temp = Array();
    foreach($sectionData['el'] as $key =&gt; $value) {
     $temp[$key] = $value['vDEF'];
    }
    $sectionArray[$sectionName][] = $temp;
   }
  }
 }
 return $sectionArray;
}

 

Vous n’avez plus qu’à appeler getFlexform2Array() dans votre main, les valeurs renseignées dans le flexform se retrouverons dans le tableau $this->lConf

Utilisation de Zend JavaBridge – Part 2

Par défaut
Business Lib
Architecture de notre librairie :
Business/
– Controler/
—- CompteControler.php
– DataHandler/
—- EjbDataHandler.php
– Dto/ (ou pojo/popo)
—- Compte.php
–Helper/
—-DtoHelper.php
datahandler/EjbDataHander.php



/**
* EJB DataHandler - S'occupe de la connexion aux services
*/
class EJBDataHandler {

protected $_contextHn;
protected $_contextService;
protected $_serviceLookup;
protected $_serviceLookupName;


/**
* Constructeur
* @param String Ip / host du serveur JBOSS
* @param String Nom du bean (service)
*/
function __construct($serviceHost, $serviceLookupName) {
$environnement = array(
"java.naming.factory.url.pkgs" => "org.jboss.naming:org.jnp.interfaces",
"java.naming.provider.url" => $serviceHost
);

// Connexion
try {
$this->_contextService = new Java("javax.naming.InitialContext", $environnement);
} catch(JavaException $e) {
$exception = java_last_exception_get();
throw new JavaException("Impossible de se connecter au(x) serveur(s) Jboss.\n".$exception->getMessage());
}

// Lookup
try {
$this->_serviceLookup = $this->_contextService->lookup($serviceLookupName);
} catch(JavaException $e) {
$exception = java_last_exception_get();
throw new JavaException("Impossible de se brancher sur le service.\n".$exception->getMessage());
}
$this->_serviceLookupName = $serviceLookupName;
}


/**
* Fonction magique permettant d'appeler les méthodes des services
* @param String Nom de la méthode
* @param Array tableau d'arguments

*/
public function __call($methode, $arguments) {
try {
$result = call_user_func_array(array($this->_serviceLookup, $methode), $arguments);
} catch(JavaException $e) {
$exception = java_last_exception_get();
throw new Exception($exception->getMessage(), $exception->getErrorNumber());
}
return $result;
}
}

Quelques explications s’imposent, commençons pour le constructeur.
Deux arguments sont attendus, le premier étant l’adresse du serveur Jboss et le second, le Bean sur lequel on se connecte. La fonction java_last_exception_get() permet de caster l’exception en un objet java du type de l’exception levée (il est fort probable que la gestion des exceptions coté métier soit très spécifique).
Nous utilisons une méthode magique en php, à savoir __call. Noter que par exemple $exception->getErrorNumber() est une méthode propre à l’exception retournée.
Passons aux controlers.
controler/Controler.php
D’abord une classe abstraite qui va nous permettre d’effectuer quelques actions communes à tous les controlers. Tous les controlers hériterons ensuite de celle-ci.


require_once('datahandler/EJBDataHandler.php');
require_once('helper/DtoHelper.php');


/**
* Classe abstraite Controler
* @abstract
*/
abstract class Controler {

public $serviceName;
public $serviceStatut;
public $serviceError;

protected $_dataHandler;

/**
* Constructeur
*/
function __construct($service) {
$this->serviceName = $service;

try {
$this->_dataHandler = new EJBDataHandler('ip_server_jboss:port', $service);
$this->serviceStatut = true;
} catch(Exception $e) {
$this->serviceStatut = false;
$this->serviceError = $e->getMessage();
}
}

/**
* Initialise un "contexte"
* @access public
*/
public function initContext($userId, $context, $lang) {
$this->_dataHandler->initContext($userId, $applicationName, $lang);
}
}

Utilisation de Zend Java Bridge – Part 1

Par défaut
Malgré que ce ne soit pas ma tasse de thé, aujourd’hui je vais m’essayer à la rédaction d’un billet un peu technique … je suis plutôt du genre codeur bourru (et barbu) qui a du mal à formaliser ses idées. N’hésitez donc pas à intervenir si vous voyez des erreurs.
Préambule

Je vais vous parler de JavaBridge, un composant où plutôt une fonctionnalité du Zend Server qui, pour faire simple, permet d’utiliser du code Java directement en PHP. A l’aide d’un exemple ces quelques billets vous monteront comment utiliser et structurer votre code afin de le rendre évolutif et mutualisable.

JavaBridge
Comme je le disais juste au dessus, JavaBridge, c’est le moyen d’utiliser des objets Java en PHP. Il existe deux « JavaBridge », le premier prenant la forme d’un module PHP indépendant et l’autre fournit avec Zend Server. Je ne me suis pas penché sur le sujet depuis longtemps mais je crois me souvenir que le premier choix comportait quelques limites, notamment au niveau des performances : une JVM de lancée par processus; Zend Server de son coté ne lance qu’une seule JVM.
Il n’y a pas meilleur exemple que le code :
$date = new Java('java.util.Date');
echo $date->getTime()

Aujourd’hui bon nombre de sociétés orientent leur architecture vers de la SOA pour des raisons de couts et d’évolutivités. Dans ce schéma on imagine donc parfaitement un serveur d’application Java (par exemple JBoss) portant le métier pour ensuite mettre à disposition un ensemble de services. En face, la partie cliente, des applications PHP diverses et variées utilisant des Frameworks (Symfony, Zend Framework) tout comme des CMS (Typo3, Drupal).

Les choses sont en place, un serveur Jboss SOA d’un coté et un Zend Server de l’autre utilisant JavaBridge. L’objectif est donc de consommer des services métiers Java en PHP. Petit exemple extrait de la page de Zend JavaBridge :
// Configuration pour EJB JBoss. Les autres serveurs d'applications Java peuvent nécessiter une configuration différente.
// Notez que le CLASSPATH doit contenir ces classes.
$envt = array(
"java.naming.factory.initial" => "org.jnp.interfaces.NamingContextFactory",
"java.naming.factory.url.pkgs" => "org.jboss.naming:org.jnp.interfaces",
"java.naming.provider.url" => " jnp://yourflowers.com:1099"
);
$ctx = new Java("javax.naming.InitialContext", $envt);

// Recherche de l'objet
$obj = $ctx->lookup("YourflowersBean");

// Ici, nous trouvons un objet - pas de gestion d'erreur dans cet exemple.
$rmi = new Java("javax.rmi.PortableRemoteObject");
$home = $rmi->narrow($obj, new Java("com.yourflowers.StoreHome"));

// $hw contient notre objet bean
$store = $home->create();

// ajoutez une commande au bean
$store->place_order($_GET['client_id'], $_GET['item_id']);
print "Order placed. Current shopping cart: ";

// récupération des données du caddie depuis le bean
$cart = $store->get_cart($_GET['client_id']);
foreach($cart as $item)

// Libére l'objet
$store->remove();

Comme vous pouvez le voir la mise en oeuvre est quand même relativement simple. Maintenant complexifions un peu la chose.

L’environnement de développement
Imaginons que nous ayons à développer une gestion de compte propre au métier d’une société au sein d’un CMS, Typo3 par exemple. Le CMS s’occupe uniquement de l’authentification front-office et nous laissons donc au serveur d’applications Java le soin de porter la gestion de compte qui comportera spécificités propres au métier de la société. Au passage, notre société s’appellera « Paypal ».
Un compte aurait comme caractéristiques le nom, le prénom, la date de naissance et le numéro de compte bancaire de la personne. Il y aurait aussi un autre type de compte, un compte dit « vérifié » où l’on aurait un peu plus d’informations : adresse postal et nom de naissance).
Bien, dans Typo3 nous aurons donc une extension que nous appellerons « gestcompte ». Dans cette extension nous aurons plusieurs plugins, l’un pour afficher les informations du compte (p1) et l’autre pour les éditer (pi2).
Assez rapidement nous allons nous rendre compte qu’une bonne partie du code risque d’être écrit plusieurs fois, notamment tout ce qui est connection au serveur JBoss. Il est aussi fort probable que nous ayons à récupérer l’adresse d’un compte ou tout autres informations depuis d’autres plugins.
Dans ce billet je m’appuie sur un IHM supporté par Typo3 mais la logique est la même que se soit pour une application « from scratch » ou conçue à l’aide d’un Framework. L’exemple est même relativement bidon :)
 
Nous allons donc essayer de développer une « librairie » mutualisable qui s’appuiera sur quelques design patterns. Nous l’appellerons « business-lib« .