Andrew Cohen pisze:
> Mariusz S. pisze:
>> Parametry zapytania GET pobierane s± w php i wstawiane do
>>
>> $xml = "<?xml version="1.0"?>
>> <root>
>> <zakladka modul="..." akcja="$_GET['akcja']">
>> ...
>> </zakladka>
>> </root>";
>
> No w³a¶nie. O to chodzi. A tego php-a przepisaæ mo¿esz czy nie mo¿esz?
> A je¶li mo¿esz, to dlaczego tego choose nie zrobisz w php? Co tam idzie
> dalej w tym kodzie? Jakie¶ PHP_XSLT_TRANSFORM($xml,'jaki¶_plik.xsl'), w
> którym to xsl gdzie¶tam masz choose. Mo¿e zmieniæ choose na php-owy
> switch i tyle. Napisz, co w takim rozwi±zaniu jest z³ego.
mhy, przerobiæ zawsze mo¿na, ale my¶la³em, ¿e mo¿na rozwi±zaæ ten
problem po stronie szablonu. W smarty nie by³o takich problemów!
Tworzenie oddzielnych plików xsl dla ka¿dej akcji w module moim zdaniem
mija siê z sensem.
Obecnie w moim systemie transformacja odbywa siê poprzez podanie nazwy
modu³u jako parametr i struktury xml
xslt::transformacja('szablony/'.$dane['modul'].'.xsl', $xml);
na wyj¶ciu otrzymuje odpowiedni± strukturê dokumentu uzale¿nion± od
wywo³ywanej akcji i bez powtarzania kodu w szablonach. Moja metoda ma
wady, ale wydaje siê mniej pracoch³onna w aktualizacji od Twojego
rozwi±zania.
Ale to dziwne, ¿e w xslt niemo¿na zastosowaæ wzorca MVC )-: