Många utav de klasser som utgör Madr webbapplikation skall skrivas om inom en snar framtid. En av de delar jag aldrig varit riktigt nöjd med är hur mina kontrollerare behandlar datatransport från modellagret till vylagret.
Min mallmotor (template engine) är transformsbaserad, och bygger på XSL via klassen XSLTPRocessor. Då XSLTPRocessor-objektet tar emot ett DOM-dokument som argument för att generera HTML, måste modellagrets datasamling förvandlas till ett sådant. Min nuvarande lösning på detta är verkligen förskräcklig:
- Begär en nästlad vektor från modellen till kontrolleraren.
- nästla vektorn ännu mer för att all data skall få plats.
- Initiera vy-objektet med vektorn som argument.
- Importera vektorn till ett DOM-dokument via DomBuilder::import($data). alla nummernycklar byts ut mot "rs".\
- Exportera och importera DOM-dokumentet igen för att leka litet med HTML_entities_decode() och HTML_entities() för att allt skall se bra ut.
- Transformera och skriv ut HTML.\
En ful och mycket otrevlig lösning att arbeta med. DOM-dokumentet som generas av ovanstående algoritm är helt befriade från logisk och semantisk struktur, vilket gör det mer komplicerat än önskvärt att skapa XSL-mallar till eländet.
Anledningen till att det blivit såhär är att jag vid implementations tidpunkt inte hade en aning om hur att bemästra DOM. Så är inte fallet idag. Jag skall därför återimplementera hela lösningen med ett globalt DOM-dokument. Datamodellen skall inte återsända vektorer, utan en elementnod med barnnoder som importeras direkt till det globala DOM-dokumentet. När mallmotorn sedan skall transformera behövs ingen löjlig importering, plus att DOM-dokumentets struktur är intakt och semantisk.
Jag satt idag och lekte med detta, då jag provade blanda två importtekniker: Vektor till DOM, och extern XML-fil till DOM. Detta finns uppe i mitt labarkiv:\