PRADO v3.0 n'est pas rétro-compatible avec les versions précédents de PRADO.
La bonne nouvelle est que les propriétés et que les évènements de la plupart des contrôles restent identiques ainsi que la syntaxe des templates qui reste largement inchangée. Par conséquent, les connaissances des développeurs des anciennes versions restent applicables dans la v3.0.
Nous résumons ci-dessous les changements les plus significatifs de la v3.0 afin d'aider les développeurs à migrer leurs applications v2.x et v1.x plus facilement, si besoin est.
La version 3.0 a complètement changé de besoin de fichiers de spécifications des composants. Il se fonde davantage sur des conventions pour définir les propriétés et les événements des composants . En particulié, une propriété est définit par la présence d'une méthode getter et/ou setter, tandis qu'un évènement est définit par l'existance d'une méthode on... .Les noms des propriétés et évènements dans la v3.0 sont tous les deux case-insensitive. Par conséquence, les développeurs sont désormais obligés de faire attention aux conversions de type lorsque la propriété d'un composant est définie. Par example, le code suivant est utilisé afin de définir la propriété Enabled propriétaire d'un TControl, qui est un type booléen,
où la fonction TPropertyValue::ensureBoolean() est utilisée afin de s'assurer que la variable est bien un booléen. Ceci car lorsque la propriété est configurée dans un template, une chaîne de caractère est passée au setter. Dans les versions précédentes, PRADO connaissait le type de chaque propriété des composants grâce aux fichiers de spécifications et se chargeait de la conversion de type pour vous.
Le contrôleur de l'application implémente désormais une architecture modulaire. Les modules peuvent être ajoutés et configurés dans la configuration de l'application. Chaque module assure une fonction particulière et ils peuvent être coordonnés entre eux par le cycle de vie de l'application. Le concept des modules de la version 2.x a été replacé dans la v3.0 par les répertoires des pages. En conséquence, le format de configuration de l'application de la v3.0 est très différent des versions précédentes.
Les pages dans la version 3.0 sont organisés dans des répertoires qui peuvent être comparés au concept des modules de la v2.x. Les pages sont demandées selon leur structure. Par exemple, une URL index.php?page=Controls.Samples.Sample1 sera utilisée pour servir une page nommée Sample1 se trouvant dans le répertoire [BasePath]/Controls/Samples, où [BasePath] se réfère au répertoire racine des pages. Le nom d'un fichier template d'une page doit avoir comme extension .page, principalement pour différencier les templates des pages des templates des contrôles qui se termineront par l'extension .tpl.
La version 3.0 redéfinit les relations entre les contrôles. En particulier, la relation parent-enfant se réfère désormais à la relation entre les contrôles et la présentation. Un nouveau nom de relation est introduit afin d'aider la gestion des identifiants des contrôles. Pour plus de détails, voir la section concernant les contrôles.
La syntaxe des contrôles dans les templates de la v3.0 est très similaire à celle des versions précédentes avec beaucoup d'améliorations. Un changement important est au sujet des expression dans le databinding. Dans la v3.0, cela est fait de la façon suivante,
Les expressions et les tags d'états ont aussi changé. Pour plus de détails, voir la section concernant la définition des templates.
Les thèmes dans la v3.0 sont définis comme les contrôles des templates avec quelques restrictions.