Project

General

Profile

Požadavek #921

Modularita

Added by Ondřej Fibich over 5 years ago. Updated over 5 years ago.

Status:
Nový
Priority:
Normální
Assignee:
-
Category:
Jádro systému
Target version:
Start date:
07/28/2014
Due date:
% Done:

0%

Estimated time:
(Total: 15.00 h)

Description

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ů.


Subtasks

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

Actions

Related issues

Related to Chyba #931: Nové UI pro nastaveníNový08/19/2014

Actions

History

#1

Updated by Ondřej Fibich over 5 years ago

  • Description updated (diff)
#2

Updated by Ondřej Fibich about 5 years ago

  • Related to Chyba #931: Nové UI pro nastavení added

Also available in: Atom PDF