PRADO 3.0 nie jest kompatybilne wstecz z wcześniejszymi wersjalmi PRADO.
Dobrą wiadomością jest, że własciwości oraz zdarzenia większości kontrolek pozostają niezmienione a składnia szablonów kontrolek pozostaje w dużej mierze niezmieniona. Dlatego więc, wiedza develoiperów dotycząca wcześniejszych wersji PRADO wciąż znajduje zastosowanie w wersji 3.0.
Kolejno podsumujemu najbardziej znaczące zmiany w wersji 3.0 aby pomóc developerom aktualizację ich aplikacji PRADO z wersji 2.x oraz 1.x jeśli wystąpi taka potrzeba.
Wersja 3.0 całkowicie zarzuciła potrzebę występowania pliku specyfikującego komponent. Polega ona obecnie bardziej na konwencji definiowania właściwości komponentu i jego zdarzeń. Uszczegóławiając, właściwość (ang. property) jest definiowana poprzez istnienie metod: getterów i/lub setterów (ang. getter and/or setter methods), natomiast zdarzenie jest zdefiniowane poprzez istnienie metod z przedrostniem on (ang. on-methods). Zarówno właściwości jak i nazwy zdarzeń są w wersji 3.0 nie są wrażliwe na wielkość liter. W konsekwencji developerzy, są teraz zobowiązaniu do troszczenia się konwersję typów, kiedy właściwość komponentu jest ustawiana. Na przykład, następujący kod jest używany do zdefiniowania metody będącej setterem dla właściwości Enabled (przyp. tłum. ang enabled - dostępny, umożliwiony) TControl, która jest typu boolowskiego: boolean,
gdzie TPropertyValue::ensureBoolean() jest używana aby ipewnić się, że wartość wejściowa jest typu boolean. Dziejse się tak ponieważ, gdy watość jest konfigurowana w szablonie, wartość łańcuchowa (ang. string value) jest przekazywana do settera. W poprzednich wersjach PRADO znało typ właściwości bazując na pliku specyfikacji i wykonywało konwersję typów za Ciebie.
Kontroler aplickacji implementuje teraz architekturę modułową. Moduły mogą być podłączone i skonfigurowane w specyfikacji aplikacji. Każdy moduł obejmuje określoną funkcjonalność a wszystkie one są koordynowane przez cykl życia aplickacji (ang. application lidecycle). Konecpcja modułów w wersji 2.x została zastąpiona w wersji 3.0 przez katalogi stron (ang. page directories). W wyniku tego format specyfikacji aplikacji (ang. application specification) w wersji 3.0 różni się od wersji wcześniejszych.
Strony w wersji 3.0 są zorganizowane w katalogach, które mogą zostać porównane do koncepcji modułów w wersji 2.x. Strony są dostępne poprzez ścieżkę do nich. Na przykład, adres URL index.php?page=Kontrolki.Przyklady.Przyklad1 będzie używany do dostępu do strony nazwanej Przyklad1 przechowywanej w katalogu [ŚcieżkaBazowa]/Kontrolki/Przyklad, gdzie [ŚcieżkaBazowa] oznacza główny katalog stron (ang. root page path). Nazwa pliku szablonu strony musi kończyć się rozszerzeniem .page, głównie, aby odróżnić szablony stron od "niestronowych" (ang. non-paged) szablonów kontrolek, których nazwa musi być zakończona rozszerzeniem .tpl.
Wersja 3.0 redefiniuje zależności pomiędzy kontrolkami. W szczególności, relacja rodzic-dziecko (parent-child relationship teraz odnosi się do relacji zawierajacej się w prezentacji kontrolek. Nowa relacja naming-container (przyp tłum. ang. naming - nazywanie, container - kontener) została wprowadzona dla lepszego zarządzania identyfikatorami ID kontrolek. Aby uzyskać więcej informacji zobacz sekcję kontrolki.
Składnia szblonów kontrolek w wersji 3.0 została podobna do tej we wcześniejszych wersjach, ale z wieloma rozszerzeniami. Główna zmiana dotyczy wyrażenia wiążącego dane (ang. databind expression), które jest wykonywane następująco
Tagi formuł oraz wyrażeń (ang. expression and statement tags) zostały zmienione w podobny sposób. Aby uzyskać więcej szczegółów zobacz sekcję definiowanie szablonów (ang. template definition).
Tematy w wersji 3.0 są definiowane jak szablony kotnrolek z kilkoma obwarowaniami.