DotclearWatch / Blog - Mot-clé - factory

[2.36] Modification des conteneurs

Jean-Christian Denis — Tue, 02 Sep 2025 09:33:00 +0200

Avec les corrections des divers bugs du coeur de Dotclear 2.36, la classe de Container a été améliorée.

Le gestionnaire de service (Container) embarqué dans Dotclear ne permettait pas de passer à ses services le container lui-même, c'est désormais possible depuis Dotclear 2.36. Une autre limite du container était qu'on ne pouvait pas récupèrer d'instance d'une service pour un usage isolé sans propager les intercations à tout le container. Pour faire simple si on modifiait les paramètres d'un service, cela modifiait ce service pour tout le script. Il est désomrais possible de créer des instances de service à usage ponctuel.

L'appel d'un service avec le paramètre NULL permet d'avoir une instance isolée de ce service. Les valeurs TRUE et FALSE de ce paramètre ont toujours les mêmes fonction qu'avant.

Voici un exemple complet montrant le passage du container au service et l'utilisation du paramétre NULL à la récupération du service :

<?php 

use Dotclear\Helper\Container\Container;
use Dotclear\Helper\Conttainer\Factories;

// Class du service
class MonService
{
    protected int $nb = 0;

    // On passe le container directement au service
    public function __construct(
        protected MonContainer $container
    ) {

    }

    // On met en mémoire du service un nombre
    public function nombre(int $nb): void
    {
        $this->nb = $nb;
    }

    // On lance un calcul en utilisant une methode du container
    public function calcul(): string
    {
        $somme = $this->container->ajoute($this->nb);

        return 'resultat : ' . $somme . "\n";
    }
}

// Class du container
class MonContainer extends Container
{
    public const CONTAINER_ID = 'moncontainer';

    public function __construct()
    {
        parent::__construct(Factories::getFactory(static::CONTAINER_ID));
    }

    // Methode qui fait une addition
    public function ajoute(int $nb): int
    {
        return $nb + $nb;
    }
}

// On ajoute le service au container
Factories::addService('moncontainer', 'monservice', MonService::class);

// On crée l'instance du container
$container = new MonContainer();

// On récupère une instance du service depuis le container
$a = $container->get('monservice');

// On lui donne un nombre
$a->nombre(2);

// On fait une première fois le calcul
echo $a->calcul(); // resultat : 4

// On donne un autre nombre à notre instance du sevice
$a->nombre(3);

// On calcul, le résultat prend en compte le dernier nombre soumis
echo $a->calcul(); // resultat : 6

// On recupère une instance du service depuis le container
$b = $container->get('monservice');

// Même sans soumettre de nombre, 
// on voit que le calcul se fait sur la même instance de service que précédement.
echo $b->calcul(); // resultat : 6

// On vérifie, et effectivement les deux instances a et b sont en réalité la même
echo $a->calcul(); // resultat : 6

// On récupère une nouvelle instance avec le parametre null
$c = $container->get('monservice', null);

// On donne à cette instance un nombre
$c->nombre(4);

// Le calcul prend bien en compte ce nombre
echo $c->calcul(); // resultat : 8

// On refait le calcul sur l'instance précédente, elle a bien gardé en mémoire le nombre précèdent
echo $b->calcul(); // resultat : 6

// Ce sont bien cette fois deux instances distinctes

// On récupère une instance du service depuis le container
$d = $container->get('monsevrice');

// On fait un calcul sans donner de nombre
echo $d->calcul(); // resultat: 6

// on voit que $c avec le paremetre null n'a pas d'influence sur les autres instances

Attention aux effets de bords, les objets partagés dans ces instances peuvent être modifiés dans une instance et renvoyer un résultat inattendu dans une autre instance !

A noter que tous les constructeurs des classes de premier niveau de Dotclear, celles qui sont disponibles dans le container principal, utilisables depuis App::xxx() ont désormais le container comme paramètre.
Par exemple classe Auth est passée de ça :

class Auth
{
    // ...
    /**
     * Constructs a new instance.
     *
     *@param   BlogInterface               $blog           The blog instance
     * @param   BlogsInterface              $blogs          The blogs handler
     * @param   ConfigInterface             $config         The configuration instance
     * @param   DatabaseInterface           $db             The database handler instance
     * @param   SessionInterface            $session        The session handler
     * @param   UserPreferencesInterface    $user_prefs     The user preferences instance
     * @param   UsersInterface              $users          The users handler
     */
    public function __construct(
        protected BlogInterface $blog,
        protected BlogsInterface $blogs,
        protected ConfigInterface $config,
        protected DatabaseInterface $db,
        protected SessionInterface $session,
        public UserpreferencesInterface $user_prefs,
        protected UsersInterface $users
    ) {
        // ...
    }
    // ...
}

à ça :

class Auth
{
    // ...
    /**
     * Constructs a new instance.
     *
     * @param   Core    $core   The core container
     */
    public function __construct(
        protected Core $core
    ) {
        // ...
    }
    // ...
}

Certains y veront le grand retour de $core, mais il n'en est rien, car cela n'est effectif que dans les classes de premier niveau, associées au container.

Appel aux classes de context

Les instances de classes appartenant aux contextes (Utility) telles que Frontend, Backend, Upgrade et Install sont désormais disponibles comme méthodes du contexte. Il n'est plus nécessaire de déclarer l'utilisation des classes comme \Dotclear\Core\Backend\Favorites::class pour les utiliser, car elles sont maintenant directement disponibles dans l'objet du contexte, ce qui donnera pour l'exemple App::backend()->favorites();

Voici une liste des classes de second niveau pour le Backend :

Dotclear\Core\Backend\Action::class => App::backend()->action(), (nouvelle classe, voir plus bas)
Dotclear\Core\Backend\Auth::class => App::backend()->auth(), (nouvelle classe, voir plus bas)
Dotclear\Core\Backend\Combos::class => App::backend()->combos(),
Dotclear\Core\Backend\Favorites::class => App::backend()->favorites(),
Dotclear\Core\Backend\Filter::class => App::backend()->filter(), (nouvelle classe, voir plus bas)
Dotclear\Core\Backend\Helper::class => App::backend()->helper(),
Dotclear\Core\Backend\Listing::class => App::backend()->listing(), (nouvelle classe, voir plus bas)
Dotclear\Core\Backend\MediaPage::class => App::backend()->mediaPage(),
Dotclear\Core\Backend\Menus::class => App::backend()->menus(),
Dotclear\Core\Backend\ModulesList::class => App::backend()->modulesList(),
Dotclear\Core\Backend\Notices::class => App::backend()->notices-),
Dotclear\Core\Backend\Page::class => App::backend()->page(),
Dotclear\Core\Backend\Resources::class => App::backend()->resources(),
Dotclear\Core\Backend\ThemeConfig::class => App::backend()->themeConfig(),
Dotclear\Core\Backend\ThemesList::class => App::backend()->themesList(),
Dotclear\Core\Backend\Url::class => App::backend()->url(),
Dotclear\Core\Backend\UserPref::class => App::backend()->userPref(),

Les nouvelles classes de Backend utiles aux listes que sont Action, Filter et Listing fournissent les instances des objets suivant :

Dotclear\Core\Backend\Action\ActionsBlogs => App::backend()->action()->blogs(...)
Dotclear\Core\Backend\Action\ActionsComments => App::backend()->action()->comments(...)
Dotclear\Core\Backend\Action\ActionsPosts => App::backend()->action()->posts(...)
Dotclear\Core\Backend\Filter\FilterBlogs => App::backend()->filter()->blogs(...)
Dotclear\Core\Backend\Filter\FilterComments => App::backend()->filter()->comments(...)
Dotclear\Core\Backend\Filter\FilterMedia => App::backend()->filter()->media(...)
Dotclear\Core\Backend\Filter\FilterPosts => App::backend()->filter()->posts(...)
Dotclear\Core\Backend\Filter\FilterUsers => App::backend()->filter()->users(...)
Dotclear\Core\Backend\Listing\ListingBlogs => App::backend()->listing()->blogs(...)
Dotclear\Core\Backend\Listing\ListingCommnets => App::backend()->listing()->comments(...)
Dotclear\Core\Backend\Listing\ListingMedia => App::backend()->listing()->media(...)
Dotclear\Core\Backend\Listing\ListingPosts => App::backend()->listing()->posts(...)
Dotclear\Core\Backend\Listing\ListingPostsMini => App::backend()->listing()->postsMini(...)
Dotclear\Core\Backend\Listing\ListingUsers => App::backend()->listing()->users(...)
Dotclear\Core\Backend\Listing\Pager => App::backend()->listing()->pager(...)

Une autre nouvelle classe fournit les instances des objets nécessaires aux connections tierces :

Dotclear\Core\Backend\Auth\Otp => App::backend()->auth()->otp(...)
Dotclear\Core\Backend\Auth\WebAuthn => App::backend()->auth()->webauthn(...)
Dotclear\Core\Backend\Auth\OAuth2Client => App::backend()->auth()->oauth2(...)

Voici une liste des classes de second niveau pour le Frontend :

Doclear\Core\Frontend\Ctx::class => App::frontend()->context(),
Doclear\Core\Frontend\Tpl::class => App::frontend()->template(),
Doclear\Core\Frontend\XmlRpc::class => App::frontend()->xmlrpc(),

Les plugins et thèmes, en pouvant accèder directement depuis le contexte à ces objets, ne devraient plus avoir à déclarer des classes appartenant aux Backend ou Frontend hormis lors de la création de liste pour étendre une classe.
.

Remplacer une classe de premier niveau

Jean-Christian Denis — Fri, 13 Oct 2023 08:00:00 +0200

Dans cet article nous allons voir de façon très succincte comment remplacer une des classes du cœur de Dotclear en utilisant un conteneur de services.

Autant le dire tout de suite, ça ne va pas servir à tout le monde, et uniquement pour des cas bien précis, par des utilisateurs connaissant cette façon de coder.

Définition

- Mais c'est quoi un conteneur, un service, une usine ?
- C'est un patron de conception aka design pattern.
- Mais encore ?

Profitant du passage aux espaces de nom PHP, le cœur de Dotclear, appelé core ou dcCore, a disparu au profit d'un conteneur qui s'occupe uniquement de fournir les classes maitresses de Dotclear, ces classes sont définies et leur objets générés par le conteneur, appelé Core. (Original comme nom !) Tout ce petit monde suivant des règles bien précises écrites dans des interfaces.
Pour faire simple:

Un service est un ensemble de méthodes dédiées à une tâche, par exemple la gestion des behaviors, regroupées dans une classe
Le conteneur Container fournit à l'utilisateur les objets prêt à l'emploi, ici App:: avec App::unService()
L'usine Factory fournit ces classes, sans que l'utilisateur sache lesquelles sont réellement chargées.
Les interfaces xxxInterface définissent les règles que doivent suivre les classes de l'usine. exemple: BehaviorInterface

Cette technique va permettre de remplacer toutes les classes accessibles depuis App::xxx()

Déclaration

Il faut commencer par déclarer notre service, une classe dédiée \Dotclear\Helper\Container\Factories est là pour ça, on va lui dire d'ajouter notre service. Le plus simple est de lui dire depuis le fichier inc/config.php de l'installation, dans l'exemple qui suit, on veut simplement remplacer une seule méthode de la classe Error :

<?php
//... contenu du fichier inc/config.php

// Notre service n'utilise pas d'espace de nom, on le récupère directement
require_once __DIR__ . '/../MyError.php';

// On dit à la maison mère que notre service va être utilisé dans le core de Dotclear pour le service ErrorInterface::class
\Dotclear\Helper\Container\Factories::addService('core', ErrorInterface::class, MyError::class);

Voilà notre service remplace celui de Dotclear.

Service

Passons à notre service. Il doit obligatoirement suivre des règles strictes pour pouvoir être utilisé à la place d'un autre, voici le contenu de notre fichier MyError.php :

<?php
// On va reprendre la classe d'erreur et ses méthodes
use Dotclear\Core\Error;
// Pas besoin d'implémenter l'interface qui l'est déjà par la classe Error
//use Dotclear\Interface\Core\ErrorInterface;

// on crée notre classe d'erreur qui va étendre celle par défaut.
class MyError extends Error
{
    // on remplace uniquement la méthode qui nous intéresse
    public function add(string $msg): void
    {
        // notre classe va arrêter net le script sur une erreur au lieu de renvoyer un bandeau par exemple
        exit($msg);
    }
}

Cet exemple est simple, il permet de montrer la mécanique d'utilisation de Factories, si vous souhaitez remplacer la gestion de connexion à la base de données cela va être bien plus compliqué !

Liste des classes maîtresses

Voici la liste des appels depuis l'application et des interfaces associées :

App::auth(): \Dotclear\Interface\Core\AuthInterface,
App::behavior(): \Dotclear\Interface\Core\BehaviorInterface,
App::blog(): \Dotclear\Interface\Core\BlogInterface,
App::blogSettings(): \Dotclear\Interface\Core\BlogSettingsInterface,
App::blogs(): \Dotclear\Interface\Core\BlogsInterface,
App::blogWorkspace(): \Dotclear\Interface\Core\BlogWorkspaceInterface,
App::categories(): \Dotclear\Interface\Core\CategoriesInterface,
App::cache(): \Dotclear\Interface\Core\CacheInterface,
App::con(): \Dotclear\Interface\Core\ConnectionInterface,
App::error(): \Dotclear\Interface\Core\ErrorInterface,
App::filter(): \Dotclear\Interface\Core\FilterInterface,
App::formater(): \Dotclear\Interface\Core\FormaterInterface,
App::lang(): \Dotclear\Interface\Core\LangInterface,
App::log(): \Dotclear\Interface\Core\LogInterface,
App::media(): \Dotclear\Interface\Core\MediaInterface,
App::meta(): \Dotclear\Interface\Core\MetaInterface,
App::nonce(): \Dotclear\Interface\Core\NonceInterface,
App::notice(): \Dotclear\Interface\Core\NoticeInterface,
App::plugins(): \Dotclear\Interface\Module\ModulesInterface,
App::postMedia(): \Dotclear\Interface\Core\PostMediaInterface,
App::postTypes(): \Dotclear\Interface\Core\PostTypesInterface,
App::rest(): \Dotclear\Interface\Core\RestInterface,
App::session(): \Dotclear\Interface\Core\SessionInterface,
App::themes(): \Dotclear\Interface\Module\ModulesInterface,
App::trackback(): \Dotclear\Interface\Core\TrackbackInterface,
App::url(): \Dotclear\Interface\Core\UrlInterface,
App::users(): \Dotclear\Interface\Core\UsersInterface,
App::userPreferences(): \Dotclear\Interface\Core\UserPreferencesInterface,
App::userWorkspace(): \Dotclear\Interface\Core\UserWorkspaceInterface,
App::version(): \Dotclear\Interface\Core\VersionInterface,

Le nom de l'interface sera le nom du service dans l'usine.

Le contenu de ce document a été écrit suivant le code de la version 2.28 de Dotclear.

Le conteneur principal

Jean-Christian Denis — Fri, 13 Oct 2023 08:00:00 +0200

La version 2.28 de Dotclear intégre un nouveau système de conteneur pour l'application qui remplace dcCore.

Grâce aux avancées de Dotclear 2.27, cette nouvelle version 2.28 peut désormais proposer l'accès à la quasi totalité de l'application à partir d'un seul point App::. Le core, aka dcCore, passe en déprécié et ses méthodes et propriétés sont regroupées dans des classes dédiées à un ensemble de tâches de même style. Une nouvelle gestion par conteneur et services accompagnée d'un nouvelle gestion d'exception permet de proposer ces classes à tout moment sans avoir besoin de les instancier. Autre nouveauté de taille qui pourra être exploitée par la suite, ces classes deviennent remplaçables ! Ce qui devra être utilisé pour des classes d'authentification ou de connexion tiers par exemple.

Pour résumer, voici deux exemples simples de la nouvelle façon d'appeler les classes de l'ancien dcCore :

// Avant 2.28 :
dcCore::app()->auth->use_prefs;
// A partir 2.28, dcAuth fait partie du conteneur et ses propriétés deviennent des méthodes :
App::auth()->prefs();

// Avant 2.28 :
dcCore::app()->getAllBlogStatus();
// A partir de 2.28 les méthodes de l'ancien dcCore sont regroupées dans des classes à thème :
App::blogs()->getAllBlogStatus();

Voici la liste complète des classes composants ce nouveau Core de Dotclear :

Configuration

App::config(): ConfigInterface
Cette classe est une nouveauté de dotclear 2.28, elle regroupe toutes les informations de configuration de l'application.

Authentification

App::auth(): AuthInterface
~~dcCore::app()->auth~~
Anciennement dcAuth, c'est la classe de gestion de l'utilisateur.
Deux nouvelles méthodes sont disponibles :

openUserCursor(): Cursor : renvoie un Cursor sur la table des utilisateurs
openPermCursor(): Cursor : renvoie un Cursor sur la table des permissions

L'utilisation d'une classe tiers d'authentification est encore permise en 2.28, mais il faudra utiliser le nouveau système de remplacement de classe par la suite.

Comportement

App::behavior(): BehaviorInterface
~~dcCore::app()->xxxBehaviorxxx(xxx)~~
Nouvelle classe de la version 2.28, elle regroupe toutes les méthodes dépréciées de dcCore en rapport aux behaviors.
L'ancienne méthode getBehaviors() est dédoublée :

getBehavior(string $behavior): array : renvoie un groupe de behaviors,
getBehaviors(): array : renvoie tous les behaviors

Blog

App::blog(): BlogInterface
~~dcCore::app()->blog, new dcBLog()~~
Anciennement dcBlog, c'est la classe de gestion du blog courant. Cette classe subit des changements majeures dans son utilisation.
Désormais cette classe existe toujours dans l'application. Il ne faut plus tester le chargement du blog avec !is_null(dcCore::app()->blog) mais App::blog()->isDefined().
Il ne faut plus créer une nouvelle instance de dcBlog lorsqu'on veut naviguer entre deux blogs en cours de script, Il faut partir de l'instance existante et charger un autre blog dedans, puis recharger le premier si besoin. On peut mettre en id vide pour décharger un blog.
Une nouvelle méthode est donc disponible :

App::blog()->loadFromBlog(string $blog_id): BlogInterface : renvoie l'instance de Blog chargé d'un autre blog

Exemple de chargement :

// On récupère l'ID de blog courant
$old_id = App::blog()->id();
// On charge le blog qu'on souhaite modifier
App::blog()->loadFromBlog('SecondBlog');
// On le modifie
App::blog()->triggerBlog();
// On recharge le blog courant
App::blog()->loadFromBlog($old_id);

De nouvelles méthodes sont disponibles :

openBlogCursor(): Cursor : Ouvre un Cursor sur la table blog
openPostCursor(): Cursor : Ouvre un Cursor sur la table post
openCommentCursor(): Cursor : Ouvre un Cursor sur la table comment
isDefined(): bool : Vérifie si un blog est chargé dans la classe ou non

Les propriétés publiques de la classe passent en déprécié, il faut désormais utiliser les méthodes idoines :

dcCore::app()->blog->id : App::blog()->id(): string
dcCore::app()->blog->uid : App::blog()->uid(): string
dcCore::app()->blog->name : App::blog()->name(): string
dcCore::app()->blog->desc : App::blog()->desc(): string
dcCore::app()->blog->url : App::blog()->url(): string
dcCore::app()->blog->host : App::blog()->host(): string
dcCore::app()->blog->creadt : App::blog()->creadt(): int
dcCore::app()->blog->upddt : App::blog()->upddt(): int
dcCore::app()->blog->status : App::blog()->status(): int
dcCore::app()->blog->settings : App::blog()->settings(): BlogSettingsInterface
dcCore::app()->blog->themes_path : App::blog()->themesPath(): string
dcCore::app()->blog->pblic_path : App::blog()->publicPath(): string

Paramètres de blog

App::blogSettings(): BlogSettingsInterface
~~dcCore::app()->blog->settings, new dcSettings();~~
Anciennement dcSettings, c'est la classe de gestion des paramètres de blog. Cette classe subit également un changement majeur dans son utilisation. Pour créer une nouvelle instance de BlogSettings, il faut utiliser une nouvelle méthode de la classe qui renverra une instance prête à l'emploie :

App::blogSettings()->createFromBlog(?string $blog_id): BlogSettingsInterface : renvoie une nouvelle instance de BlogSettings.

On peut également utiliser App::blog()->settings()->createFromBlog(?string $blog_id).
Ses méthodes en xxxNamespace() passent en déprécié, il faut utiliser leurs méthodes associées xxxWorkspace().

Espace de paramètres de blog

App::blogWorspace(), App::blog()->settings()->get(xxx), App::blog()->settings()->addWorspace(xxx)
Comme la classe précédente une nouvelle méthode fait son apparition pour créer une nouvelle instance de BlogWorkspace :

App::blogWorkspace()->createFromBlog(?string $blog_id, string $workspace, ?MetaRecord $rs = null): BlogWorkspaceInterface : renvoie une nouvelle instance de BlogWorkspace.

Une nouvelle méthode est disponible :

openBlogWorkspaceCursor(): Cursor : renvoie un Cursor sur la table des espaces de paramètres de blog

La méthode dumpNamespace() passe en déprécié, il faut utiliser dumpWorkspace().

Blogs

App:blogs()
~~dcCore::app()->xxxBlogsxxx()~~
Nouvelle classe de la version 2.28, elle regroupe toutes les tâches en rapport à la gestion des blogs.
Changement par rapport à la version 2.27, la méthode getBlog() renverra toujours une instance de Blog. Ceci est dû au changement de comportement de la classe Blog.

Cache

App:cache()
~~dcCore::app()->emptyTemplatesCache(), dcCore::app()->cache~~
Nouvelle classe de la version 2.28, Elle inclue une méthode de l'ancien core :

emptyTemplatesCache(): void : vide le cache des templates

Et une nouvelle méthode pour le cache des dépôts de modules :

emptyModulesStoreCache(): void : vide le cache des dépôts tiers

Elle remplace également la gestion des fichiers et timestamps utilisés pour le cache coté public et qui était dans un simple tableau dcCore::app()->cache :

resetFiles(): void : Raz de la litses des fichiers
addFile(string $file): void : Ajoute un fichier
addFiles(array $files): void : Ajoute plusieurs fichiers
getFiles(): array : Renvoie la liste des fichiers
function resetTimes(): void : Raz des timestamps
addTime(int $time): void : Ajoute un timestamp
addTimes(array $times): void : Ajoute plusieurs timestamps
getTimes(): array : Renvoie la listes des timestamps

Catégories

App::categories(), App::blog()->categories()
~~dcCore::app()->blog->categories, new dcCategories()~~
Anciennement dcCategories, c'est la classe de gestion des catégories d'un blog. Elle inclut désormais la classe NestedTree.
Comme vu sur de précédentes classes une nouvelle méthode fait son apparition pour créer une nouvelle instance de Categories :

App::blog()->categories()->createFromBlog(string $blog_id): CategoriesInterface : renvoie une nouvelle instance de Categories.

Une nouvelle méthode est disponible :

openCategoryCursor(): Cursor : renvoie un Cursor sur la table des catégories

Toutes les propriétés de la classe passent en protected.

Connexion

App::con()
~~dcCore::app()->con~~
Nouvelle classe de la version 2.28, elle permet le lien entre l'ancien chargement de gestionnaire de base de donnée et le nouveau système de chargement des classes du Core. L'utilisation d'une classe tiers de connexion est encore permise en 2.28, mais il faudra utiliser le nouveau système remplacement de classe par la suite.
Elle inclut désormais le préfixe des tables disponibles en faisant App::con()->prefix().

Déprécié

App:deprecated()
Cette classe est disponible dans le Core ou en version statique. Elle permet de loguer en mode DEV d'éventuelles méthodes dépréciées.

Erreur

App::error()
~~dcCore::app()->error~~
C'est la classe de gestion d'erreur non bloquante du Core.
Sa méthode toHTML() passe en dépréciée, il faut utiliser votre propre parser à la place.

Filtre

App::filter()
~~dcCore::app()->wiki, dcCore::app()->xxxWikiXxx(), dcCore::app()->HTMLfilter()~~
Nouvelle classe de la version 2.28, elle regroupe toutes les méthodes et propriétés dédiées à la syntaxe wiki et HTML de texte.

Formateur

App:formater()
~~dcCore::app()->xxxFormaterXxx()~~-
Nouvelle classe de la version 2.28 elle regroupe toutes les méthodes de gestion des formateurs de texte.

Langue

App::lang()
~~dcCore::app()->lang~~
Nouvelle classe de la version 2.28, elle s'occupe de la langue courante.
Deux méthodes sont disponibles :

getLang(): string : renvoie le code de la langue courante
setLang(string $lang): void : enregistre le code de la langue courante.

Lexique

App::lexical()
~~dcUtils::xxxlexicalxxx()~~
Nouvelle classe de la version 2.28, elle regroupe toutes les méthodes en rapport au champs lexical d'une langue.

Log

App::log()
~~dcCore::app()->log~~
Anciennement dcLog, cette classe s'occupe de la gestion de log.
Une nouvelle méthode est disponible :

openLogCursor(): Cursor : Ouvre un Cursor sur la table de log

L'ancienne méthode getTable() passe en dépréciée, il faut utiliser la constante de classe disponible sur App::log()::LOG_TABLE_NAME.

Média

App::media()
~~dcCore::app()->media~~
Anciennement dcMedia, cette classe s'occupe de la gestion des média et comme vu précédemment, il ne faut plus créer une instance de dcMedia mais toujours utiliser celle du Core.
Pour définir le type de media, auparavant dans son constructeur, il faut utiliser la nouvelle méthode :

setFilterMimeType(string $type): void : définit le type de media

Ses propriétés publiques deviennent dépréciées, il faut par exemple utiliser la méthode :

getThumbnailFilePattern(string $type = ''): string : renvoie la définition d'un pattern.

D'autres nouvelles méthodes sont disponibles :

openMediaCursor(): Cursor : ouvre un Cursor sur la table des média
postMedia(): PostMediaInterface : retourne l'instance de PostMedia

Métadonnée

App::meta()
~~dcCore::app()->meta~~
Anciennement dcMeta, cette classe gère les métadonnées de dotclear.
Une nouvelle méthode est disponible :

openMetaCursor(): Cursor : ouvre un Cursor sur la table des métadonnées

Nonce

App::nonce()
Nouvelle classe de la version 2.28, elle regroupe les méthodes en rapport à la validation de formulaires.
L'ancienne méthode formNonce() est dédoublée :

getFormNonce(): string : renvoie le contenu HTML
formNonce(): Hidden : renvoie l'élément de Form de type Hidden

Notification

App::notice()
~~dcCore::app()->notices~~
Anciennement dcNotices, cette classe gère en base les notices.
Une nouvelle méthode est disponible :

openNoticeCursor(): Cursor : ouvre un Cursor sur la table des notifications

Media de billets

App:postMedia(), App::media()->postMedia()
~~dcCore::app()->postmedia~~
Anciennement dcPostMedia, cette classe gère les media de billets.
Une nouvelle méthode est disponible :

openPostMediaCursor(): Cursor : ouvre un Cursor sur la table des media de billets

Les constantes des noms des tables de media et post media sont disponibles dans cette classe :

App::postMedia()::MEDIA_TABLE_NAME
App::postMedia()::POST_MEDIA_TABLE_NAME

A noter que lorsqu'un blog est chargé dans la classe Blog via App::blog()->loadFromBlog(), il est également chargé dans l'instance de la classe PostMedia.

Type de billets

App::postTypes()
~~dcCore::app()->getPostxxxURL(), dcCore::app()->xxxPostType()~~
Nouvelle classe de la version 2.28, elle regroupe les méthodes en relation aux types de billets.
Les anciennes méthodes sont toujours utilisables mais il est recommandé d'utiliser l'autre nouvelle classe de définition d'un type de billet PostType. (cf billet sur dcCore déprécié)

Service REST

App::rest()
~~dcCore::app()->xxxRestXxx()~~
Nouvelle classe de la version 2.28, elle regroupe les méthodes relatives au service REST.

Session

App::session()
Nouvelle classe de la version 2.28, elle adapte l'ancienne classe de gestion de session à la nouvelle gestion de classe de Core.
Une nouvelle méthode est disponible pour créer simplement une nouvelle session à partir d'un nom de cookie (pratique pour les plugins et thèmes) :

App::session()->createFromCookieName(string $cookie_name): SessionInterface

Rétroliens

App::trackback()
Anciennement dcTrackback, cette classe gère les rétroliens et pingback.
Une nouvelle méthode est disponible :

openTrackbackCursor(): Cursor : ouvre un Cursor sur la table des rétroliens

Préférences utilisateur

App::userPrerefences()
Anciennement dcPrefs, cette classe gère les préférences utilisateur. Elle est disponible pour l'utilisateur en cours dans App::auth()->prefs(). Comme nombre de classes de Core, cette classe est toujours disponible et instanciée dans App::userPreferences(), pour avoir une nouvelle instance il faut donc utiliser sa méthode :

createFromUser(string $user_id, ?string $user_workspace = null): UserPreferencesInterface : Créé une nouvelle instance des préférences utilisateur

Espace de préférences utilisateur

App::userWorkspace(), App::auth()->perfs()->get(xxx), App::auth()->prefs()->addWorspace(xxx)
Comme la classe précédente une nouvelle méthode fait son apparition pour créer une nouvelle instance de UserWorkspace :

createFromUser(?string $user_id, string $workspace, ?MetaRecord $rs = null): UserWorkspaceInterface : renvoie une nouvelle instance de UserWorkspace.

Une nouvelle méthode est disponible :

openUserWorkspaceCursor(): Cursor : renvoie un Cursor sur la table des espaces de préférences utilisateur

Utilisateurs

App::users()
Nouvelle classe de la version 2.28, elle regroupe toutes les méthodes relatives aux utilisateurs.

Versions

App::version()
~~dcCore::app()->xxxVersionXxx()~~
Nouvelle classe de la version 2.28, elle gère les version de module (et core) en base.
Une nouvelle méthode est disponible :

openVersionCursor(): Cursor : ouvre un Cursor sur la table des versions

Autres

De plugs certaines classes plus spéciales sont accessibles depuis App::xxx() :

App::backend() : Gestion de l'interface d'administration
App::frontend() : Gestion de l'interface publique
App::url() : Anciennement dcUrlHandler de dcCore::app()->url
App::task() : Uniquement utilisé par les plugins et thèmes pour tester le contexte avec App::task()->checkContext(...)

En savoir plus

dcCore déprécié

Le contenu de ce document a été écrit suivant le code de la version 2.28 de Dotclear.