Pour cela, nous disposons d’une classe, à partir de laquelle, les objets que nous souhaitons sérialiser devront hériter. De la sorte, vos objets pourront être passés très simplement d’une Activity à une autre.

public class CSerializable implements Serializable {

    public byte[] serialize () throws IOException {
        ByteArrayOutputStream bos = new ByteArrayOutputStream ();
        ObjectOutput out = new ObjectOutputStream (bos);
        out.writeObject (this);
        out.close ();
        return bos.toByteArray ();
    } // serialize ();

    public Object unserialize (byte[] b) throws IOException,
            ClassNotFoundException {
        ByteArrayInputStream bis = new ByteArrayInputStream (b);
        ObjectInputStream in = new ObjectInputStream (bis);
        Object object = in.readObject ();
        bis.close ();
        in.close ();
        return object;
    } // unserialize ();

}; // CSerializable;

Pour continuer, voici un exemple vraiment très simple d’objet devant hériter de la classe CSerializable.

public class CTest extends CSerializable {
    protected String title, content;
    protected Date date;

    public void populate (byte[] serialize)
            throws IOException, ClassNotFoundException {
        CTest object = (CTest)unserialize (serialize);
        setTitle (object.getTitle ());
        setContent (object.getContent ());
        setDate (object.getDate ());
    } // populate ();

    public String getTitle () {return title;}
    public void setTitle (String title) {this.title = title;}

    public String getContent () {return content;}
    public void setContent (String content) {this.content = content;}

    public Date getDate () {return date;}
    public void setDate (Date date) {this.date = date;}
}; // CTest;

Le passage de l’objet de l’Activity 1 vers la 2 se résumer alors à ce qui va suivre:

// CActivity1
CTest test = new CTest ();
test.setTitle ("Mon titre");
test.setContent ("Mon contenu");
test.setDate (new Date ());
Intent intent = new Intent (getApplicationContext (), CActivity2.class);
intent.putExtra ("test", test.serialize ());
startActivity (intent);

// CActivity2
byte[] testArray = getIntent ().getExtras ().getByteArray ("test");
CTest test = new CTest ();
test.populate (testArray);

Mais pour un grand nombre d’entres-nous, se pose directement la question: « Oui mais, ça donnerait quoi sur les vieux navigateurs ? » … pour ne pas citer Internet Explorer et ses nombreuses tentatives de réajustement (c’est tellement vrai)! Ceci-dit, il faut tout de même avouer qu’ils ont fait de très gros progrès depuis IE9, on en serait presque tout émoustillé.

Malheureusement, ces vieux navigateurs occupent une petite part du marché qui titillent encore notre conscience professionnelle pour finalement nous pousser à réaliser l’effort ultime (ok … j’exagère un peu)!

Cas d’école: les bords arrondis

C’est certainement la propriété que j’utilise à coup sûr lorsque je commence l’intégration d’un projet. Il faut reconnaître, que même très léger, un bord arrondi c’est toujours plus beau et sympatique qu’un bord qui ne l’est pas, en plus les graphistes s’en donnent à coeur joie.

En décortiquant un peu le CSS mis en place à cette occasion, voilà ce que l’on peut trouver (rien de bien extraordinaire):

border-radius: 5px;
-moz-border-radius: 5px;
-webkit-border-radius: 5px;

On distingue très rapidement les propriétés dites « standards » de celles qui sont propriétaires -moz, -webkit et j’en passe. Oui mais voilà, dans ce cas précis, il n’existe aucun moyen en CSS d’appliquer ce type de propriété sous Internet Explorer < 9. C’est bien dommage mais fort heureusement, au moins deux possibilités s’ouvrent généreusement à nous: l’utilisation d’images et celui du javascript.

Les images

Avantages

• Si elles sont bien découpées, elles prendront moins de temps à charger qu’un script JS ;
• Le rendu est scrupuleusement identique à celui fourni par nos graphistes.

Inconvénients

• S’il s’agit de PNG transparent, sous IE 6 cette option est à bannir … ou alors il faudrait faire intervenir du JS … heeuu …?
• Au contraire, si vos images sont mal traitées, le temps de chargement deviendrait alors problèmatique (il n’y a très rarement qu’un seul bord arrondi … donc il y aura forcement plusieurs images).

Le Javascript

Avantages

• Plus aucune question à se poser, il suffit de lire la doc de la bibliothèque de votre choix, et si elle est correctement développée, le problème de compatibilité ne se posera même pas.

Inconvénients

• Le temps de chargement du script, ajouté à cela, son temps d’exécution ! Il faut penser à remettre les choses dans leurs contextes, les vieux navigateurs n’étaient pas autant optimisés que maintenant, le javascript était beaucoup plus long à s’exécuter ;
• Si le Javascript est désactivé … ç’est encore possible ça ? … hey ho c’est fini le temps des gifs animés (une période traumatisante) !

Quelle option adopter alors ?

Personnellement j’ai choisi de bannir catégoriquement l’utilisation du JS à cause des inconvénients cités ci-dessus qui laissent trop souvent apparaître un effet désagréable de clipping en fin de chargement des pages. De la même manière, j’évite au maximum (voir complètement) l’utilisation d’images, mais il faut dire que ça peut parfois vous sauver la vie.

Qu’elle est la solution miracle ?

J’ai pris pour habitude d’appliquer la méthode de dégradation passive … oula, mais qu’est-ce qu’il nous raconte lui ? Le but consiste à intégrer normalement une charte graphique en laissant le rendu se dégrader visuellement sur les anciens navigateurs. Lorsque j’emploie le terme de dégradation, je parle uniquement du rendu, en aucun cas l’affichage du site ne doit en être altéré, ou alors la phase d’intégration aura été un échec (… mais pourquoi ma colonne s’affiche-t-elle dans le footer … ?).

Cela signifie tout simplement qu’il n’y aura pas de bord arrondi … mais est-ce que c’est si grave lorsqu’on sait qu’un très faible pourcentage des internautes en sera affecté ? Est-ce que ça les empêchera de naviguer correctement et confortablement sans temps de chargement supplémentaire, ou effets visuels désagréables ?

Fort heureusement, on rencontre ce genre de problème uniquement sous Internet Explorer. En règle général il y a très peu de surprises sur les autres navigateurs, je vous conseille au passage ce site qui référence très bien les compatibilités CSS avec tous les navigateurs dans toutes les versions (je suis fan).

Il s’agit d’un exemple concret qui peut très bien s’appliquer à d’autres propriétés CSS ou pseudos-selecteurs.

Pour terminer, je pense aussi que laisser croire les internautes qu’ils sont toujours à la pointe de la technologie par l’émulation n’est pas la meilleure des solutions. Libre à vous d’appliquer la méthode de votre de choix, car l’avantage du travail d’intégration, c’est que chacun peut faire comme il veut même si au final on se pose tous les mêmes questions.

Après 3 à 4 bonnes semaines de travail (environ 40h), j’ai enfin réussi à terminer une première version de ma toute première application sous Android. Son but est de vous permettre de contrôler votre PC depuis une tablette (de préférence car mieux adaptée qu’un portable avec un petit écran). En somme, votre tablette devient votre souris et votre clavier.

Pour cela, il faut au préalable lancer un programme sur votre ordinateur (pour le moment uniquement compatible sous Windows), qui va permettre de réaliser les échanges PC <> Android. Saisir un identifiant, un mot de passe, et d’activer les communications.

Ensuite, il ne vous reste plus qu’à lancer l’application sous Android et de vous connecter au PC pour lequel nous venons juste d’activer les communications.

Au début, l’utilisation peut paraître relativement déroutante car j’ai pour le moment souhaité aller au plus simple. Lorsque vous déplacerez le pointeur depuis votre tablette, les mouvements se feront de manière proportionnelle avec la résolution de votre écran. En clair, le coin supérieur-gauche de votre tablette correspond au coin supérieur-gauche de votre écran, et pour le coté droit, c’est la même chose.

Pour le clic-gauche, il faut garder une pression sur la tablette pour le contrôle du pointeur, et en réaliser une supplémentaire pour lancer cette action. Le plus simple est d’utiliser les deux mains, une pour le contrôle du pointeur (tout comme vous le faites en gardant votre main sur la souris), et une autre pour réaliser les actions (clic-gauche / clic-droit). Le clic-droit quant à lui, est réalisé à l’aide d’une troisième pression supplémentaire.

Il est aussi possible d’utiliser le clavier, pour cela il suffit d’aller dans le menu (durant la phase de contrôle) et de l’activer. Attention, dans cette première version toutes les touches ne sont pas encore supportées. Pour l’instant vous pouvez utiliser les lettres (minuscules et non accentuées), les chiffres, ainsi que les touches espace, entrer et supprimer.

Je ne sais pas encore si je vais continuer le développement, mon objectif étant simplement d’apprendre à développer sous Android par le biais de travaux que je publierai très certainement sur mon blog.

Coté serveur (PC):
Développé avec JAVA, utilise SWT pour l’interface.

Coté client (Tablette):
Développé en JAVA, API 7 (2.1-update1) de Android.

Les communications sont réalisées en TCP pour garder les connexions ouvertes entre les clients et le serveur, et en UDP pour la phase de contrôle.

Uniquement testé depuis ma tablette ASUS EEE Pad Transformer TF101 et mon Galaxy TEOS, ça devrait normalement fonctionner quasiment partout … à voir!

Une ListView va nous permettre d’ajouter des éléments en liste au moment de l’exécution de l’application, mais lorsqu’on ne connait ni le nombre ni le contenu de ces derniers, notamment lors de la récupération d’un flux RSS qu’on souhaite organiser en liste, le développement peut tenir du parcours du combattant (en moins épuisant … ouf!).

J’ai trouvé beaucoup d’exemples sur internet, mais personnellement, je ne voulais pas bloquer l’utilisateur avec une boîte de chargement, mon souhait était qu’il puisse utiliser la liste et son contenu, pendant que cette dernière continue à se remplir tranquillement.

La première étape consiste à définir nos layouts: main.xml et listentry.xml

• main.xml correspond au layout principal qui va définir l’organisation des éléments de notre application (ici juste une liste), et listentry.xml celui des éléments de la liste.
• Je ne vais pas expliquer l’organisation des fichiers XML, tout simplement parce que ce n’est pas l’objet de cet article, et surtout parce que d’autres sites le font déjà très bien (cf: le lien que j’ai donné en tout début d’article).

Ensuite, il ne nous reste plus qu’à lier le tout sous JAVA, instancier correctement nos objets et lancer la récupération de notre contenu de manière totalement asynchrone. Pour cela, nous allons utiliser AsyncTask, qui a pour principale fonction de lancer un processus en tâche de fond sans pour autant bloquer le thread principal qui gère l’application. En somme, si les traitements sont longs, l’application ne sera pas bloquée.

Voici le profil de la classe que j’utilise pour mes besoins qui hérite de AsyncTask.

private class CAsyncTask extends AsyncTask<Void, Void, Void> {
    protected Void doInBackground (Void... unused);
    protected void onPostExecute (final Void unused);
} // CAsyncTask ();

doInBackground  parle d’elle-même, c’est ici que nous allons réaliser nos traitements susceptibles de prendre du temps.

onPostExecute sera automatiquement appelée lorsque la tâche aura terminée ses traitements.

Pour plus d’infos, je vous conseille d’aller jetter un petit coup d’oeil par ici : http://developer.android.com/reference/android/os/AsyncTask.html

Pour terminer il est important de noter qu’on ne peut pas modifier les éléments du thread principal sans en avoir l’autorisation, vous ne montez pas dans une voiture alors qu’elle roule à vive allure (… j’éspère), ici c’est un peu la même chose. Afin de pouvoir modifier la liste pour y ajouter des éléments, il va falloir faire appel à la méthode runOnUiThread de notre Activity qui attend en paramètre un objet de type Runnable.

activity.runOnUiThread (new Runnable () {
    public void run () {
        HashMap<String, String> map = new HashMap<String, String> ();
        map.put ("title", it);
        map.put ("description", "Pause de "+ sleep + " ms");
        listItem.add (map);
        adapter.notifyDataSetChanged ();
    } // run ();
});

Et voilà! Notre liste se met gentillement à jour sans bloquer l’utilisation de l’application avec une boite de chargement.

Télécharger les sources

Pour plus de clarté dans mon article, les classes et objets créés depuis la plateforme seront suivis par un eZ, en revanche, lorsque je parlerai de classe ou d’objet PHP, il n’y aura pas de distinction particulière.

Pour la création d’un datatype, il est donc important de dissocier ce principe de classes/objets eZ, car en PHP, un datatype c’est une classe composée de plusieurs méthodes regroupant tous les traitements qu’il pourra rencontrer tout au long de son utilisation aussi bien coté classe que objet eZ.

Pour illustrer cet article, j’ai décidé de développer un exemple vraiment très basique utilisant la Google Map. Lors de la création d’un objet eZ, l’utilisateur pourra choisir un point à positionner sur la carte, les coordonnées seront enregistrées en base pour une utilisation coté front (pas développée dans cette première partie).

Création de l’arborescence de l’extension

Tout d’abord, nous devons créer l’arborescence de notre extension, à suivre scrupuleusement pour éviter tout problème d’exécution! Attention au nom que vous donnerai à votre extension, il faut absoluement éviter qu’il entre en conflit avec celui d’une autre extension. Le mieux est de choisir un préfixe que vous utiliserez dans toutes celles que vous développerez à l’avenir. Pour notre exemple j’ai choisi gmapv3.

Les dossiers ne sont volontairement pas dépliés, comme vous pouvez le constater, on trouve à une exception près les mêmes répertoires que vous avez très certainement déjà rencontrés lors du développement d’un projet lambda. Et pour cause, une extension peut nécessiter l’utilisation de CSS, de JavaScript et même d’images, alors pourquoi changer la logique organisationnelle quand elle marche si bien.

Les fichiers de configuration

Il faut commencer par créer les fichiers content.ini.append.php et design.ini.append.php dans le repertoire settings, ajoutez-y respectivement les lignes suivantes:

content.ini.append.php

<?php /* #?ini charset="utf-8"?

[DataTypeSettings]
ExtensionDirectories[]=gmapv3
AvailableDataTypes[]=gmapv3

*/ ?>

Ici on indique à la plateforme le chemin vers notre extension, en précisant que dans notre cas, elle contiendra un datatype. Et oui, une extension n’est pas qu’un datatype, elle peut contenir des modules, des template operators et bien plus encore!

design.ini.append.php

<?php /* #?ini charset="utf-8"?

[ExtensionSettings]
DesignExtensions[]=gmapv3

[StylesheetSettings]
CSSFileList[]=gmapv3.css

[JavaScriptSettings]
JavaScriptList[]=jquery-1.6.1.js
JavaScriptList[]=gmapv3.js

*/ ?>

Dans ce fichier, on informe eZ que notre extension va nécessité l’utilisation de templates, et de surcroît qu’elle aura besoin de charger des feuilles de style et du JavaScript pour fonctionner correctement.

Pour terminer, il suffira de créer deux fichiers PHP dans le répertoire datatypes/gmapv3: gmapv3.php et gmapv3type.php. La classe CGmapv3Type (gmapv3type.php) doit impérativement dérivée de eZDataType, de ce fait, elle sera utilisée comme un datatype grâce à la surcharge de certaines méthodes. Pour ce qui est de CGmapv3, elle nous permettra d’interagir coté template (en frontend), pour en extraire aisément les valeurs stockées (latitude et longitude), nous verrons un peu plus en détail son fonctionnement dans la suite de cet article.

Un peu d’intégration

Le template utilisé par l’objet eZ sera à placer dans le répertoire template/content/datatype/edit/ et devra porter le nom du datatype en cours de développement (gmapv3.tpl). Ce dernier se compose de deux champs de saisie de type hidden qui contiendront les coordonnées qui seront mises à jour lorsque l’utiliseur positionnera son pointeur sur la carte, et d’un morceau de code JavaScript nécessaire pour instancier et utiliser la Google Map dans un conteneur HTML. Je ne vais pas aborder le déroulement du code, mais j’invite les plus curieux d’entre-vous à jeter un coup d’œil au script (au sens figuré) même s’il n’a rien de bien extraordinaire (merci à l’API de Google très bien documentée et illustrée d’exemples!).

Les deux champs de saisi doivent porter un nom correctement composé, sans quoi, il deviendrait impossible d’en récupérer les valeurs surtout si nous souhaitons créer une classe de contenu eZ avec deux attributs de type gmapv3. La meilleure méthode reste celle proposée par la plateforme dans tous ses datatypes, en ajoutant préfixe et suffixe à la valeur des noms que nous souhaitons donner à nos input:

<input type="hidden" name="{$attribute_base}_gmapv3_lat_{$attribute.id}" ... />
<input type="hidden" name="{$attribute_base}_gmapv3_lng_{$attribute.id}" ... />

De la sorte, on s’assure de garder une unicité avec le reste des attributs de l’objet eZ.

Développement du datatype

La classe CGmapv3Type

Puisque notre classe hérite de eZDataType, vous vous doutez bien qu’il y aura des méthodes à surcharger qui seront utilisées par le système. Pour ce tutoriel, nous allons uniquement nous interesser à son développement coté objet eZ. Pour ce faire, nous aurons besoin d’utiliser les méthodes suivantes:

public function objectAttributeContent ($contentAttribute);

Le paramètre $contentAttribute est un objet de type eZContentObjectAttribute, et comme sous eZ tout est objet, tous sont identifiés par un ID, l’objet est automatiquement passé par la plateforme, il nous appartient de l’utiliser correctement pour nos besoins. Notez que l’objet PHP $contentAttribute correspond à l’attribut de l’objet eZ de type gmapv3 en cours d’utilisation.

Cette méthode doit retourner un objet ou directement le contenu stocké. Pour un eZString, c’est la chaine de caractères qui sera retournée, pour des datatypes légèrement plus compliqués, il est préférable d’utiliser un objet que nous verrons plus loin dans le tutoriel, il s’agit de la classe CGmapv3.

Cette méthode sera appelée à divers moment du code, notamment lorsque vous ferez appel à $contentAttribute->content (); mais aussi dans vos templates coté front par exemple où {$node.data_map[gmapv3].content} retournera l’objet CGmapv3 instancié avec les bonnes valeurs (latitude et longitude).

public function validateObjectAttributeHTTPInput ($http, $base, $contentAttribute);

• $http va nous permettre de récupérer les valeurs passées par le fomulaire à l’aide de la méthode POST ;
• $base contient le début de l’attribute name qu’il faudra utiliser dans le template ;
• $contentAttribute, tout comme la méthode objectAttributeContent correspondra à un objet PHP de l’attribut de type gmapv3 de l’objet eZ courant.

Cette méthode a pour unique but de retourner un état de validation des valeurs qui ont été transmises par le formulaire. Dans notre cas, les données à enregistrer doivent impérativement être des flottants. Le cas échéant, l’utilisateur en sera informé par un message d’erreur, et aucune donnée ne sera enregistrée pour être publiée. Elle est donc appelée avant fetchObjectAttributeHTTPInput que nous utiliserons pour la sauvegarde des données en base.

public function fetchObjectAttributeHTTPInput ($http, $base, $contentAttribute);

Les paramètres sont identiques à ceux de la méthode validateObjectAttributeHTTPInput. Dans notre exemple, elle est appelée en dernier par le système même si la méthode de validation retourne une erreur.

C’est ici que nous allons récupérer les valeurs du formulaire pour les enregistrer en base, et pour cela eZ met à notre disposition le champ data_text. Je ne vais pas expliquer de quelle façon tout est stocké et ni-même dans quelle table, tout d’abord parce que ce n’est pas l’objet de cet article, mais surtout parce qu’il serait trop long de le faire ici. Pour information, sachez que vous disposez en réalité de 3 champs: data_int, data_float et data_text. Il n’est pas nécessaire de les utiliser tous les trois, mais il est important de souligner leur existance, car si vous êtes curieux et que vous avez déjà parcouru le code de certains datatypes natifs du système, vous vous apercevrez très vite que eZString utilise data_text, eZInteger data_int, et d’autres peuvent utiliser 2 voire 3 de ces champs, ça dépend donc de ce que vous aurez besoin de stocker et surtout de quelle manière vous souhaiterez le faire… alors comment stocker une latitude et une longitude ? En structurant vos données avant de les enregistrer dans le champ data_text. Je ne sais pas réellement pourquoi, mais chez eZ, c’est le XML qui est utilisé dans je pense 100% des cas (je ne suis pas allé vérifier), mais rien ne vous empêche de sérialiser un tableau! Et c’est précisément ce que je vais faire dans mon exemple. Du coup, notre champ data_text contiendra des données facilement exploitables!

Avant d’enregistrer quoi que ce soit, il est d’abord nécessaire de récupérer les valeurs transmises par le formulaire:

$id = $contentAttribute->attribute ('id');

$gmapv3 = $contentAttribute->content ();
$gmapv3->setLat ($http->postVariable ($base.'_gmapv3_lat_'.$id));
$gmapv3->setLng ($http->postVariable ($base.'_gmapv3_lng_'.$id));

Comme je l’expliquais plus tôt dans l’article, $contentAttribute contient tout ce dont nous avons besoin pour interagir avec les différentes couches du système.

• $contentAttribute->attribute (‘id’) retourne l’identifiant de l’attribut de l’objet eZ de type gmapv3 courant;
• $contentAttribute->content () retourne un objet de type CGmapv3 (voir la méthode objectAttributeContent).

Pour terminer il ne nous reste plus qu’a sérialiser le tout pour le stocker en base dans le champ data_text:

$contentAttribute->setAttribute ('data_text', $gmapv3->encode ());

La classe CGmapv3

class CGmapv3 {

  private $lat, $lng;

  public function attributes ();
  public function hasAttribute ($name);
  public function attribute ($name);

  public function encode ();
  public function decode ($str);

  public function getLat ();
  public function getLng ();

  public function setLat ($lat);
  public function setLng ($lng);

}; // CGmapv3;

Les 3 méthodes suivantes seront nécessaires pour le moteur de template, en effet, comment connaitre le nom des propriétés à récupérer depuis un template si on ne l’indique pas à la plateforme.

• public function attributes ();
• public function hasAttribute ($name);
• public function attribute ($name);

La méthode attribute nécessite une attention particulière. En effet, c’est elle qui aura pour lourde tâche de retourner une valeur lorsque cela sera nécessaire, notamment dans nos templates. Pour récupérer par exemple la latitude, vous aurez besoin de faire {$node.data_map[gmpav3].content.lat}. Rappelez-vous, content est un objet de type CGmapv3 et eZ peut retourner l’attribut lat uniquement parce qu’il en a eu connaissance à un moment du code, tout dabord parce que vous le lui avez indiqué via la méthode attributes qui retourne un tableau contenant le nom des attributs potentiellement accessibles, et ensuite parce que vous retournez une valeur depuis la méthode attribute:

public function attribute ($name) {
  switch ($name) {
    case 'lat': return $this->getLat ();
    case 'lng': return $this->getLng ();
  }
  eZDebug::writeError (
    "Attribute '$name' does not exist",
    'CGmapv3::attribute'
  );
  return null;
} // attribute ();

Pour conclure

Le développement d’un datatype nécessite de bonnes bases en POO sans quoi il serait difficile de comprendre le mécanisme d’héritage et de surcharge. Cela dit, ce type de développement mérite une attention particulière sur le déroulement du processus où il est important de comprendre pourquoi et à qu’elle moment les méthodes sont susceptibles d’être appelées. Pour le moment, je me suis attaqué uniquement à la partie objet eZ du datatype. Dans un prochain article, nous traiterons la partie classe eZ, où nous pourrons paramétrer certaines fonctionnalités de la Google Map comme le niveau de zoom, le type d’affichage etc…

N’oubliez pas d’activer l’extension en l’indiquant dans votre fichier settings/overrides/site.ini.append.php en ajoutant la ligne suivante à la section [ExtensionSettings]:

ActiveExtensions[]=gmapv3

sans oublier de régénérer l’autoload pour qu’elle soit correctement prise en compte:

./bin/php/ezpgenerateautoloads.php -e

Télécharger les sources

• la surcharge des templates par défauts (ou standards) ;
• la création d’un template pour la vue d’une nouvelle classe de contenu ;
• la surcharge de vos propres templates.

Pour ces trois points, le développement d’un template (avec les template operators) est identique, mais dans bien des cas, nous verrons qu’il faudra impérativement modifier un fichier de configuration dédié à ce type d’entreprise.

Point sur l’arborescence

Il est important de bien comprendre l’arborescence du répertoire design, car c’est dans ce dernier que vous passerez la majorité de votre temps de développement!

L’arborescence qui vous est présentée ci-dessus sera très certainement différente de la vôtre, tout simplement parce que chaque projet est différent, et qu’il n’est jamais nécessaire de surcharger tous les templates par défauts. Dans cet exemple, les répertoires nommés « standard » et « website » sont tous deux des enfants directs du répertoire « design/ ». Ainsi, tous vos templates devront être créés, soit dans le répertoire « webiste/templates/ », soit dans « website/override/templates/ ».

Quelle est la différence alors ? C’est justement ce que nous allons voir.

La surcharge des templates standards

eZ Publish vous propose un grand nombre de templates par défauts dits « standards ». Ils sont tous stockés dans le même répertoire et facilement identifiables par le nom qu’ils portent. Prenons pour exemple le fichier « standard/template/pagelayout.tpl » (pas visible dans l’arborescence du dessus), il s’agit du template général de mise en page qui contiendra dans 90% des cas la structure même de votre site, le DOCTYPE, les balises head, body ect… vous pouvez le comparer à un fichier d’index, c’est en quelque sorte le point d’entrée de votre site internet.

Comme vous pouvez le voir sur l’image ci-dessus, un fichier de même nom se trouve aussi dans le répertoire « website/templates/ », il s’agit là de notre propre template, et c’est ainsi qu’eZ Publish va le prendre en compte pour laisser de coté celui par défaut. On parle alors de surcharge ou d’écrasement car il va tout simplement être utilisé prioritairement à celui proposé par la plateforme. Notez qu’il est fortement déconseillé de modifier un template standard, procédez ainsi lorsque vous aurez besoin d’utiliser un template existant qui ne répond pas complètement à vos attentes.

Création d’un nouveau template

La création d’un nouveau template intervient lorsqu’il est nécessaire d’afficher la vue d’une classe de contenu. Nous allons prendre pour exemple le développement simple d’un template de page type contenant les attributs suivants:

• Nom (name) de type chaine de caractères ;
• Nom court (short name) de type chaine de caractères facultative ;
• Description court (short_description) de type bloc de texte facultatif;
• Corps (body) de type bloc de texte riche.

Après avoir créé la classe de contenu depuis le backend de votre site internet [Administration > Classes > Content > Nouvelle classe] (cf le schéma ci-dessous), il devient nécessaire d’en faire un template et d’indiquer au système quel fichier utiliser pour afficher sa vue lorsque nécessaire.

Voici le template de la vue « full » (pleine page) de notre page type:

<h1>{$node.data_map['name'].content|wash()}</h1>
{attribute_view_gui attribute = $node.data_map['body']}

Comme vous pouvez le constater ici, rien de bien compliqué, notre h1 va contenir le titre de la page, et le corps quand a lui sera affiché à l’aide de « attribute_view_gui ». Pour le moment, vous pouvez le voir comme un raccourci syntaxique, on aurait très bien pu écrire {$node.data_map['body'].content|wash()}, mais attribute_view_gui va faire appel à un template tout comme celui-ci, qui pourrait être beaucoup plus complexe et terme de traitement. Ça sera notamment le cas lorsqu’il faudra afficher les champs d’un formulaire de contact (article à venir). Ce fichier (template) sera à mettre dans le répertoire « website/override/templates/full/ » et devra, pour notre exemple, porter le nom « page.tpl ».

La dernière étape consiste à modifier le fichier de configuration « /settings/website/overrides.ini.append.php » afin d’indiquer au système quel fichier utiliser pour l’affichage de notre vue. Pour cela, il suffit d’ajouter les lignes suivantes:

[page]
# Source de la surcharge, toutes les vues pleines (full) font appel à ce template.
source=node/view/full.tpl
# Fichier qui sera utilisé en surcharge.
MatchFile=full/page.tpl
# Répertoire racine.
Subdir=templates
# Condition à respecter pour utiliser ce template, page correspond au
# nom donné à la classe de contenu lors de sa création.
Match[class_identifier]=page

Pour terminer, en backend, il ne vous reste plus qu’à créer votre page sous le noeud « Accueil » et de vider votre cache pour que les modifications apportées à votre fichier de configuration soient bien prises en compte!

Surcharge de vos propres templates

Le dernier point qui me semble important de souligner reste celui de la surcharge de vos propres templates. Prenons pour exemple un site avec une colonne latérale composée de plusieurs blocs (le coté a peu d’importance). Admettons que vous souhaitez afficher dans cette dernière 2 blocs en accueil puis 3 sur le reste du site, pour cela, la surcharge de template répondra parfaitement à nos besoins. En effet, un site contient toujours qu’une seule page d’accueil, alors pourquoi ne pas s’en servir comme référence pour notre surcharge ?

Tout d’abord, vous aurez besoin de créer votre template de colonne à 3 blocs dans le répertoire « website/templates/ » portant le nom « colonne.tpl » par exemple. Ce fichier devra être inclus depuis un autre template à l’endroit où vous souhaitez que votre colonne apparaisse dans votre code HTML:

{include uri="design:colonne.tpl"}

A cet instant précis, le site contiendra toujours une colonne à 3 blocs, même en page d’accueil, c’est alors qu’entre en jeu la surcharge. On commence par créer un fichier de même nom (plus simple pour l’exemple, mais vous pouvez très bien le nommer comme bon vous semble) qu’on placera dans le répertoire « website/override/templates/ ». Enfin, il ne nous reste plus qu’à indiquer au système dans quel cas utiliser notre template de colonne à 2 blocs! Pour cela, il suffit simplement d’ajouter la section suivante dans votre fichier de configuration (/settings/website/overrides.ini.append.php):

[page]
 # Chemin vers le fichier source à surcharger (indiquer le chemin
 # complet si nécessaire /MON/REPERTOIRE/TEMPLATE.TPL).
 source=colonne.tpl
 # Chemin du fichier utilisé pour la surcharge (indiquer le chemin
 # complet si nécessaire /MON/REPERTOIRE/TEMPLATE.TPL).
 MatchFile=colonne.tpl
 # Nom du répertoire contenant la surcharge.
 Subdir=templates
 # Condition à respecter pour prendre en compte notre surcharge,
 # ici on attend que l'identifiant du nœud soit 2 (homepage).
 Match[node_id]=2

Après avoir vidé le cache, un petit rafraichissement de notre page d’accueil s’impose pour voir que désormais notre colonne contient 2 blocs, et 3 sur le reste du site.

Sous eZ Publish l’arborescence de vos projets s’organisera toujours autour de nœuds. Tout comme sur votre OS favori, un nœud pourra prendre la forme d’un répertoire ou d’un fichier qui sera alors appelé un objet. Un objet ne peut exister sans nœud, et c’est pourquoi un nœud fera toujours référence à un objet grâce à son id. Ces notions sont très importantes à assimiler car lors de vos futurs développements vous vous apercevrez très vite que toutes vos vues s’organiseront toujours autour de ces nœuds. Et mes classes de contenu alors ? Par abus de langage, un objet est une classe, à la différence qu’un objet existe sous un nœud (il a été créé), et qu’une classe n’est rien d’autre qu’un modèle de données.

Pour schématiser ces notions:

• Accueil
  • Rubrique 1
  • Rubrique 2
  • Page

Accueil est un nœud d’id 2, on l’appelle le RootNode car c’est le nœud le plus haut dans votre arborescence, il est normalement impossible de le supprimer et il existe par défaut. Ce nœud fait référence à un objet de type homepage, et si vous avez suivi jusqu’à présent, homepage est une classe de contenu. Un nœud ou plus précisément une classe de contenu pourra adopter le comportement de conteneur, c’est le cas de notre RootNode capable de contenir des enfants (Rubrique 1, Rubrique 2 etc…). Ce comportement sera à signaler lors de la création/modification de vos classes de contenu en cochant simplement la case conteneur. De ce fait, même un objet de type page pourra avoir des enfants!

• Un noeud est représenté par son node_id et fait référence à un objet grâce à son object_id ;
• Un objet est représenté par son object_id et fait référence à une classe par son class_id ;
• Une classe de contenu est représentée par son class_id, c’est un modèle de données constitué d’un ou plusieurs attributs typés (ligne de texte, bloc de texte, champ mail, bloc XML etc…), on les appelle datatypes.

Si vous voulez aller plus loin, sachez que même les datatypes ont un id, donc lorsque vous allez créer les différents attributs qui composeront vos futurs classes de contenu, ils se verront attribuer un identifiant unique. Pour le moment je ne suis pas suffisamment expérimenté dans ce domaine pour vous apporter plus de précisions, mais sachez qu’il est tout a fait possible de créer vos propres datatypes (en PHP). Ce qui montre bien une fois encore que vous pourrez réellement faire ce que vous voulez avec eZ Publish.

Pour les rubriques et les pages, le raisonnement reste identique en tout point, une classe de contenu pourra être utilisée dans un ou plusieurs nœuds. Il n’y a en théorie aucune limite, vous avez la possibilité d’en créer autant que nécessaire, sans même vous soucier de l’impact que cela pourrait avoir sur votre site et sa gestion … si ce n’est son ergonomie, mais là c’est une autre histoire!

Une première approche

Le CMS peut paraître relativement indigeste pour un grand nombre de développeurs non-avertis, tout simplement parce qu’eZ Publish c’est avant tout des centaines de fichiers et de dossiers… très bien organisés! Rassurez-vous, avec le temps on fini par s’y retrouver très facilement, d’autant plus que lors d’un développement lambda, vous passerez près de 90% de votre temps dans ces deux répertoires :

• design: contient ce qui touche de près comme de loin à l’élaboration de vos pages (html, css, js, images etc…) ;
• settings: fichiers de configurations (.ini).

Il faut savoir qu’eZ Publish fonctionne en Modèle-Vue-Contrôleur, où toutes les vues seront des templates facilement personnalisables à l’aide de surcharges (selon les cas) définies dans un fichier de configuration bien spécifique. Notez que cette logique s’applique aussi-bien en front qu’en backend.

Sous eZ Publish, tout est objet

La force du CMS réside dans sa conception même. Admettons que vous souhaitez créer un template de page simple qui comporte un titre principal, une description courte et un corps.

Pour commencer, il suffira de vous rendre dans le manager et d’y créer une classe de contenu nommée « page » (son type) composée des attributs cités précédemment (name, description, body) eux aussi typés (ligne de texte, bloc de texte, éditeur wysiwyg). On remarque une forte analogie avec le modèle objet des langages de programmation, c’est normal puisqu’il s’agit réellement d’une classe comme vous avez très certainement l’habitude d’en créer en PHP ou en JAVA. Ensuite, lors de l’intégration, il faudra simplement créer un fichier page.tpl (dossier design) qui réalise les différents traitements (à l’aide de templates operators) pour l’affichage de nos différents éléments (les attributs cités plus haut). Pour terminer, vous aurez besoin d’indiquer à la plateforme quel template utiliser pour les objets de type « page », le tout dans d’un fichier de configuration nommé overrides.append.ini.php (dossier settings). La procédure restera identique pour toutes les classes de contenu que vous aurez besoin de créer par la suite.

En résumé: Création de la classe de contenu » Intégration (template) » Ajout de la classe dans les settings.

Une histoire de cache !

Sous eZ Publish, vous vous apercevrez très vite que tout est fait pour optimiser votre temps de développement, mais en contre-partie, votre site pourra parfois afficher des délais de réponses trop élevés pour internet. Pour pallier à ce manque de réactivité, et en vue du grand nombre de fichiers de configuration et de templates que vous aurez besoin de créer pour vos futurs projets, eZ Publish va tout mettre en cache … ou presque. La conséquence d’un tel comportement ? Un temps de réponse optimal avec des pages qui s’affichent très rapidement (sauf au premier chargement des vues qui seront alors mises en cache). Du peu que j’ai pu constater, le framework va stocker certaines de vos règles de configuration (les fichiers ini), vos templates et les différentes références de vos images, des tailles pré-définies susceptibles d’être utilisées en front et/ou backend.

L’aide au développement

Pour vous accompagner dans vos différentes phases de développement, eZ Publish propose un mode de débogage qui vous permettra entre autres de dépister les petites comme les plus grosses erreurs. Cet outil s’avère très pratique lorsque le résultat d’un traitement n’est pas celui escompté en vous indiquant précisément l’origine de l’erreur. En plus de ça, il affiche le nom des templates utilisés pour vos pages, et pour ma part, c’est ce qui rend son utilisation incontournable. En effet, lorsqu’on débute (et même des semaines plus tard), on ne connait pas toujours le chemin complet des templates standards à surcharger pour nos besoins, grâce à cette aide, fini les longues minutes de recherche dans le répertoire des templates par défauts.

En conclusion

Avec le recul, on s’aperçoit vite qu’eZ Publish a tout ce qu’il vous faut pour mettre en place des sites administrables robustes et sécurisés. De base, il propose une large palette de classes de contenu modifiables à souhait. Bien entendu, comme nous venons de le voir, il est aussi possible d’en créer autant que vous le souhaitez en ne partant de rien. Il n’est pas nécessaire d’avoir de très lourdes connaissances en PHP, en effet, avec eZ Publish vous devrez vous familiariser avec les templates operators qui permettent de récupérer les informations d’un objet à afficher lors du développement de vos templates  (titre d’une page, son contenu riche etc…). En revanche, si vous souhaitez développer des extensions, il faudra mettre les mains dans le cambouis. Fort heureusement, rien d’insurmontable et le site officiel propose de nombreux tutoriaux qui vous permettront d’arriver à vos fins.

Il faudra faire avec le cache, ne pas oublier de le désactiver lors de vos développements et surtout le vider régulièrement, sans oublier d’utiliser le mode de débogage et ainsi vous faire gagner un temps précieux.

Pour ma part, à l’heure où je rédige cet article je suis en plein dans mon 4me projet sous eZ Publish, je me rend compte sans grande surprise qu’il n’y a vraiment pas de limites. eZ Publish est développé de tel sorte que vous pourrez réellement faire de l’outil ce que vous en voulez!

Quelques liens utiles :

• http://ez.no/fr
• http://share.ez.no

1. L’interface

L’interface se compose uniquement de deux éléments:

• Un bouton ‘Parcourir…’ qui va nous permettre d’aller récupérer notre fichier ;
• Une barre de progression, qui s’affichera au lancement de l’upload.

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" creationComplete="init();">
  <mx:Script>
      <![CDATA[
          import aruiz.CUpload;
          private function init ():void {
              new CUpload (browseButton, progressBar);
          } // init ();
      ]]>
  </mx:Script>
  <mx:Button id="browseButton" label="Parcourir..."></mx:Button>
  <mx:ProgressBar id="progressBar" label="" visible="false"></mx:ProgressBar>
</mx:Application>

Comme vous pouvez le constater, l’interface a été volontairement réduite au strict minimum. Pour notre upload, nous utiliserons la classe CUpload qui attend deux paramètres: le bouton ‘Parcourir…’ et la barre de progression (ID des éléments concernés).

2. La classe CUpload

Voici la signature de type des différentes méthodes de la classe:

• private function initListeners ():void;
• public function browse (e:MouseEvent):void;
• private function selectHandler (e:Event):void;
• private function errorHandler (e:IOErrorEvent):void;
• private function progressHandler (e:ProgressEvent):void;
• private function completeHandler (e:Event):void;

La plus importante est initListeners, elle va se charger comme son nom l’indique, d’initialiser tous les écouteurs d’événements. Dans ce cas précis on parle de programmation événementielle. Tout simplement parce que lors d’un upload, il y a différentes phases qu’il est important de prendre en considérations, sans quoi il serait totalement impossible de lier toutes les actions entre-elles.

• browse est appelée lors du click sur le bouton ‘Parcourir…’, elle a en charge d’ouvrir une fenêtre qui va permettre aux utilisateurs de choisir un fichier à transférer ;
• selectHandler est appelée lorsqu’un fichier a été choisi par l’utilisateur, l’upload peut alors commencer ;
• errorHandler parle d’elle même, nous ne sommes pas à l’abri d’une erreur, il faut pouvoir la capturer pour stopper tout traitement et en avertir l’utilisateur ;
• progressHandler va nous permettre de connaître l’avancement du transfert. Comment ? A l’aide du paramètre ‘e’ de type ProgressEvent qui contient toutes les informations nécessaires. Ainsi notre barre de progression sera mise à jour de la sorte: progressBar.setProgress (e.bytesLoaded, e.bytesTotal);
• completeHandler sera appelée en fin d’upload si tout s’est correctement déroulé.

3. Coté serveur (PHP)

Les traitements sont identiques à ceux d’un upload classique en HTML/PHP. En effet, il suffit juste d’utiliser la variable globale $_FILES (un tableau associatif) qui contient toutes les informations relatifs à notre upload. Là aussi, le code source a été volontairement simplifié pour aller à l’essentiel. Gardez en tête qu’un upload quel qu’il soit reste sensible d’un point de vu de la sécurité, il faudra donc réaliser une batterie de test afin d’être sûr que les fichiers répondent bien à certains critères, notamment leur type.

Le script est appelé en fin d’upload lorsque tout a été entièrement transféré sur le serveur. Si un ajout en base ou l’envoi d’un email est nécessaire, c’est à ce niveau du code qu’il faudra ajouter des fonctionnalités supplémentaires. Inutile donc de faire appel à un script PHP supplémentaire depuis la méthode completeHandler.

4. Conclusion

Cet article n’a rien de bien extraordinaire tellement l’upload a été vu et revu sur de nombreux blogs à travers le web. Cependant, j’ai reçu une demande d’aide de la part d’un internaute, et c’est ce qui a motivé ce court développement. Le point fort de Flex, est qu’il permet de filtrer avant tout upload les types de fichiers autorisés, cela dit, rien n’empêche de cacher du code malveillant (PHP) dans une image … Durant la phase de test, j’ai noté que les fichiers de plus de 2MO n’étaient pas transférés. C’est tout à fait normal, si c’est votre cas, il va falloir changer certaines règles de configuration (php.ini).

Si vous avez des questions, le blog est fait pour ça

Voici les sources!

HTLM:

<div class="list">
  <div class="child">
    <div>toto</div>
    <div>aime</div>
  </div>
</div>

Javascript:

$(document.body).ready (function () {
    $('div.list').resizable ({
        alsoResize: '.child',
        handles: 's',
        minHeight: 150,
        maxHeight: 300,
        minWidth: 230,
        maxWidth: 230
    });
});

div.list est correctement redimensionnable, c’est div.child qui va contenir mes éléments en overflow:auto. Si vous avez bien regardé la portion de javascript ci-dessus, la propriété alsoResize permet de définir un autre élément à redimensionner en même temps que div.list… ouf!