Projekt

Obecné

Profil

Požadavek #921

otevřený

Modularita

Přidáno uživatelem Ondřej Fibich před více než 9 roky(ů). Aktualizováno před více než 9 roky(ů).

Stav:
Nový
Priorita:
Normální
Přiřazeno:
-
Kategorie:
Jádro systému
Cílová verze:
Začátek:
2014-07-28
Uzavřít do:
% Hotovo:

0%

Odhadovaná doba:
(Celkem: 15:00hod)

Popis

Motivace

V současné době je nutné všechny součásti FreenetISu udržovat a poskytovat jako jeden celek. Tento stav je nevhodný, jelikož různé subjekty mají různé požadavky na úlohu FreenetISu a zároveň je obtížné udržovat jeden velký celek. Ve verzi 1.1 proto vznikla možnost vypínat různé části FreenetISu, jedná se ale pouze o pseudomoduly, které neumožňují snadně rozšířit funkcionalitu FreenetISu a zabránit jeho bobtnání.

Analýza

Požadavky spojené s modularizací:
  • možnost závislosti mezi moduly k jednosměrnému sdílení prostředků
  • možnost vývoje modulů třetími stranami
  • různé licencování modulů
  • modularita na úrovni UI, databáze, internacionalizace a knihoven
  • zpětná kompatibilita současného kódu
  • jednoduchá dekompozice stávajícího stavu na moduly
  • zavádění a odstranění modulů za běhu
  • možnost poskytovat moduly v samostatných balíčcích

Návrh

V současné době je celkový koncept architektury systému navržen pomocí architektonického vzoru MVC. Rozšíření o novou funkcionalitu tedy zjednodušeně spočívá v přidání nových modelů, řadičů, pohledů a dodatečně také knihoven. Modularizaci systému lze proto do jisté míry docílit oddělením těchto komponent zodpovědných za jednu funkci systému/soubor vázaných funkcí do samostatného modulu a následnou kompozicí modulů, jejímž výsledkem je systém samotný. Pro takovou strukturu systému lze použít architektonický vzor HMVC.

Zjednodušeně lze HMVC chápat tak, že existuje nějaký "root" modul, pokud nedokáže obsloužit požadavek (nemá pro něj namapovaný řadič), tak se pokusí hledat v hierarchii podmodulů, dokud se nenajde někdo, kdo požadavek obslouží. Oproti MVC je tedy nutné trochu složitější a pomalejší routování (lze řešit pomocí cache). Navíc musí být také jasně definována hierarchie modulů (pro routování, sdílení zdrojů a splnění závislostí mezi moduly).

Modularita na úrovni knihoven a helperů

Každý modul "dováží" své knihovny a helpery, ale zároveň mohou být tyto zdroje mezi moduly sdíleny. Při sdílení se dodržuje hierarchie modulů.

Modularita na úrovni databáze

Podobně jako u knihoven může modul definovat libovolný počet vlastních modelů. Mimo model je samozřejmě nutné vytvořit/upravit schéma DB tabulek. Každý modul proto bude obsahovat stejný mechanismus pro update databáze jako obsahuje FreenetIS teď a tedy také každý modul bude mít nezávislou verzi což umožní oddělit vývoj modulů.

Mechanismus pro update databáze bude rozšířen o odstranění schémat vytvořených modulem tak, aby bylo možné modul odinstalovat. Modifikace nebo odstranění sloupců tabulek vytvořených jiným modulem nebude povoleno, při přidání sloupce do tabulky jiného modulu nebudou moct být na sloupec aplikovány integritní omezení, jelikož by to mohlo způsobit problémy v modulu, ze kterého tabulka pochází.

Modularita na úrovni UI

Lze ji rozdělit na dva principy:

  1. samostatné stránky - tj. modul chce být zodpovědný za celkové zobrazení stránky systému
  2. komponované stránky - na zobrazení stránky systému se může (ale nemusí) podílet více modulů

Samostatné stánky jsou jednoduše řešitelné pomocí HMVC. Vytvoří se nový řadič, který se namapuje na nové URL. Částečně zabírá i do druhého principu, jelikož je někdy nutné do ovládacích prvků systému nějakým způsobem vložit odkaz na stránku (např. odkaz do hlavního menu).

Komponované stránky jsou mnohem složitější úkol. Části stránky je nutné rozdělit do jednoznačně identifikovaných komponent, jejichž dílčí součásti musí být možné dynamicky přidávat z jiného modulu (např. sloupec tabulky - a s tím spojená modularizace DB dotazu, pole formuláře, odkaz, ...).

První princip lze implementovat jen s minimálními dopady na existující kód, druhý princip vynucuje mohutné úpravy v dotčených částech systému. Nejdříve bude proto implementován první princip a následně poté po studii proveditelnosti bude následovat implementace druhého principu.

Modularita internacionalizace

Překlady budou jako celá architektura uspořádány hierarchicky a navíc bude možné z nižších modulů hierarchie přetěžovat překlady z modulů vyšších.

Implementace

Bude vyjádřena hierarchií podúkolů.


Dílčí úkoly 1 (1 otevřený0 uzavřených)

Požadavek #928: Adresářová struktura pro podporou modulů s jmennými prostory PHP třídNovýOndřej Fibich2014-07-28

Akce

Související úkoly 1 (1 otevřený0 uzavřených)

související s Chyba #931: Nové UI pro nastaveníNový2014-08-19

Akce

Aktualizováno uživatelem Ondřej Fibich před více než 9 roky(ů)

Aktualizováno uživatelem Ondřej Fibich před více než 9 roky(ů)

  • související s Chyba #931: Nové UI pro nastavení přidán

Také k dispozici: Atom PDF