🚀 go-pugleaf

Mariusz S. pisze:
> czy istnieje jakiś sposób aby importować szablony xslt dynamicznie?

   Jeśli wierzyć w to, co pisze na http://www.w3.org/TR/xslt20/#locating-modules to wartość href musi być URI reference. Nie jestem pewien, ale wydaje mi się, że to implikuje, że to nie jest expression i przez to nie możesz tam wpisywać wyrażenia XPath (czyli np. "//plik").
   Taka sama sytuacja byłaby, gdybyś chciał sobie np. potworzyć dynamicznie zmienne i pisał

<xsl:for-each select="1 to 10">
  <xsl:variable name="concat(mojaZmienna,.)" select="." />
</xsl:for-each>

   chcąc otrzymać zmienne mojaZmienna1, mojaZmienna2, mojaZmienna3 itd. Wartość atrybutu name jest typu qname, który musisz tam wpisać wprost, więc tego dynamicznie nie wygenerujesz.

Przeglądałem dokumentację i wiem, że zaprezentowane przeze mnie 
przykłady są błędne. Chodziło tylko o zobrazowanie problemu.

Szukam sposobu na dynamiczne pobieranie szablonów np:

<xsl:apply-templates select="." mode="$plik"/>
<!-- Tylko zobrazowanie problemu -->

Chodzi oto aby pobierać odpowiedni szablony dla zawartości xml.

Obecnie stosuje instrukcje warunkowe, ale to nie jest najlepsze rozwiązanie.

--
Pozdrawiam
Mariusz

Andrew Cohen pisze:
> Mariusz S. pisze:
>> czy istnieje jakiś sposób aby importować szablony xslt dynamicznie?
> 
>   Jeśli wierzyć w to, co pisze na 
> http://www.w3.org/TR/xslt20/#locating-modules to wartość href musi być 
> URI reference. Nie jestem pewien, ale wydaje mi się, że to implikuje, że 
> to nie jest expression i przez to nie możesz tam wpisywać wyrażenia 
> XPath (czyli np. "//plik").
>   Taka sama sytuacja byłaby, gdybyś chciał sobie np. potworzyć 
> dynamicznie zmienne i pisał
> 
> <xsl:for-each select="1 to 10">
>  <xsl:variable name="concat(mojaZmienna,.)" select="." />
> </xsl:for-each>
> 
>   chcąc otrzymać zmienne mojaZmienna1, mojaZmienna2, mojaZmienna3 itd. 
> Wartość atrybutu name jest typu qname, który musisz tam wpisać wprost, 
> więc tego dynamicznie nie wygenerujesz.

Użytkownik "Mariusz S." <seraf1@poczta.onet.pl> napisał w wiadomości 
news:galtep$9n0$1@news.onet.pl...
> Przeglądałem dokumentację i wiem, że zaprezentowane przeze mnie przykłady 
> są błędne. Chodziło tylko o zobrazowanie problemu.
>
> Szukam sposobu na dynamiczne pobieranie szablonów np:
>
> <xsl:apply-templates select="." mode="$plik"/>
> <!-- Tylko zobrazowanie problemu -->
>
> Chodzi oto aby pobierać odpowiedni szablony dla zawartości xml.

Transformacje, przed jej wykonaniem mozesz... stransformowac ;>

sz. 

Mariusz S. pisze:
> Przeglądałem dokumentację i wiem, że zaprezentowane przeze mnie 
> przykłady są błędne. Chodziło tylko o zobrazowanie problemu.
   Może problem tkwi gdzie indziej? Co Ci daje trzymanie URI szablonów w jakimś pliku XML?

> Obecnie stosuje instrukcje warunkowe, ale to nie jest najlepsze 
> rozwiązanie.
   A jak to wygląda? Możesz dać fragment kodu?

Andrew Cohen pisze:
> Mariusz S. pisze:
>> Przeglądałem dokumentację i wiem, że zaprezentowane przeze mnie 
>> przykłady są błędne. Chodziło tylko o zobrazowanie problemu.
>   Może problem tkwi gdzie indziej? Co Ci daje trzymanie URI szablonów w 
> jakimś pliku XML?

Głównie chodzi oto aby importować szablon pod konkretną akcję.
Jeżeli wywołam parametr GET ?akcja=lista to automatycznie pobierany jest 
szablon odpowiadający za wyświetlenie danych w tabelce.
Natomiast jak wywołam parametr GET ?akcja=dodaj to wywoływany jest 
formularz. Obecnie rozpoznaje akcję przy pomocy <xsl:choose> ale nie 
jest to najlepsze rozwiązanie.

<?xml version="1.0"?>
<root>
   <layout>szablon.xsl</layout>
   ...
</root>

> 
>> Obecnie stosuje instrukcje warunkowe, ale to nie jest najlepsze 
>> rozwiązanie.
>   A jak to wygląda? Możesz dać fragment kodu?

<xsl:template match="zakladka" mode="Akcja">
   <xsl:choose>
      <xsl:when test="./@akcja='dodaj'">
         <xsl:apply-templates select="." mode="Dodaj"/>
      </xsl:when>
      <xsl:otherwise>
         <xsl:apply-templates select="." mode="Lista"/>
      </xsl:otherwise>
   </xsl:choose>
</xsl:template>

Użytkownik "Mariusz S." <seraf1@poczta.onet.pl> napisał w wiadomości 
news:gam47c$tmc$1@news.onet.pl...

> <xsl:template match="zakladka" mode="Akcja">
>   <xsl:choose>
>      <xsl:when test="./@akcja='dodaj'">
>         <xsl:apply-templates select="." mode="Dodaj"/>
>      </xsl:when>
>      <xsl:otherwise>
>         <xsl:apply-templates select="." mode="Lista"/>
>      </xsl:otherwise>
>   </xsl:choose>
> </xsl:template>

<xsl:template match="zakladka">
    ...

<xsl:template match="zakladka[@akcja='dodaj']">
    ...

sz. 

Mariusz S. pisze:
> Jeżeli wywołam parametr GET ?akcja=lista to automatycznie pobierany jest 
   A w jaki sposób przechodzisz od zapytania GET do szablonu, w którym jest choose?

> 
> <xsl:template match="zakladka">
>     ...
> 
> <xsl:template match="zakladka[@akcja='dodaj']">
>     ...

Niestety tak być nie może ponieważ jest mode="Dodaj" i to on odpowiada 
za wywołanie odpowiedniego szablonu.

mode="Dodaj" równa się GET ?akcja=Dodaj tak jest obecnie

<xsl:template match="zakladka" mode="Dodaj">
...
</xsl:template>

Andrew Cohen pisze:
> Mariusz S. pisze:
>> Jeżeli wywołam parametr GET ?akcja=lista to automatycznie pobierany jest 
>   A w jaki sposób przechodzisz od zapytania GET do szablonu, w którym 
> jest choose?

każdy moduł ma swój plik główny np. kontakt.xsl i obecnie w nim 
importuje <xsl:import ... /> wszystkie potrzebne szablony.
A w szablonie <xsl:apply-templates select="." mode="Body"/> znajduje się 
jeszcze <xsl:template match="zakladka" mode="Akcja"> z choose.

Chciałbym uzyskać takie efekt, aby pozbyć się choose z szablonu "Akcja" 
i robić to automatycznie.

<?xml version="1.0" encoding="UTF-8" ?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
version="1.0">

<xsl:import href="head.xsl"/>
<xsl:import href="body.xsl"/>
<xsl:import href="kontakt_dodaj.xsl"/>
<xsl:import href="kontakt_lista.xsl"/>
<xsl:output method="xml" doctype-public="-//W3C//DTD XHTML 1.0 
Strict//EN" 
doctype-system="http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd" 
version="1.0" encoding="UTF-8" indent="yes"/>
   <xsl:template match="system">
     <html lang="pl">
       <head>
         <xsl:apply-templates select="." mode="Head"/>
       </head>
       <body>
         <xsl:apply-templates select="." mode="Body"/>
       </body>
     </html>
</xsl:template>
</xsl:stylesheet>

Mariusz S. pisze:
> mode="Dodaj" równa się GET ?akcja=Dodaj tak jest obecnie
   Skąd się bierze to "równa się"? W jaki sposób przerabiany jest parametr zapytania GET na coś w XSLT?

Użytkownik "Mariusz S." <seraf1@poczta.onet.pl> napisał w wiadomości 
news:gam5ai$1n5$1@news.onet.pl...

> Niestety tak być nie może ponieważ jest mode="Dodaj" i to on odpowiada za 
> wywołanie odpowiedniego szablonu.

Dopoki nie transformujesz po stronie klienta to co w GET moze ustalac 
odpalana transformacje, ktora zainkluduje co wspolne dla wszystkich.

sz.

szomiz pisze:
> Dopoki nie transformujesz po stronie klienta to co w GET moze ustalac 
> odpalana transformacje, ktora zainkluduje co wspolne dla wszystkich.

   Tak, tylko że właśnie sęk w tym, w jakim języku jest "może ustalać". Bo może właśnie chodzi o to, że nie może ustalać, ponieważ już dostaje przetworzone zapytanie GET w postaci XML-a i tego przetworzenia nie może tykać, a co najwyżej może sobie potransformować w XSLT. Przynajmniej ja to tak rozumiem i dlatego pytam o to, w jaki sposób z GET przechodzi się do tego XSLT, żeby przenieść problem dynamicznego importowania szablonów poza XSLT.

Użytkownik "Andrew Cohen" <cohen72@o2.pl> napisał w wiadomości 
news:gam8hb$ai4$2@news.onet.pl...
> szomiz pisze:
>> Dopoki nie transformujesz po stronie klienta to co w GET moze ustalac 
>> odpalana transformacje, ktora zainkluduje co wspolne dla wszystkich.
>
>>>   Tak, tylko że właśnie sęk w tym, w jakim języku jest "może ustalać".

W kazdym. Nie znam jezyka (a nawet srodowiska), w ktorym wykorzytsanie 
danych przychodzacych w GET determinowalo by uzycie czegokolwiek.

> Bo może właśnie chodzi o to, że nie może ustalać, ponieważ już dostaje 
> przetworzone zapytanie GET w postaci XML-a i tego przetworzenia nie może 
> tykać,

Tykac moze w dowoly sposob. Czasami moze musiec zachowac oryginalne 
zapytanie (ale wtedy raczej nie GET...) w niezmienionej postaci. To jak 
roboczo wykorzysta kopie otrzymanych danych jest jego sprawa.

> No nie rob se jaj.

Nawzajem.

sz.

Andrew Cohen pisze:
> Mariusz S. pisze:
>> mode="Dodaj" równa się GET ?akcja=Dodaj tak jest obecnie
>   Skąd się bierze to "równa się"? W jaki sposób przerabiany jest 
> parametr zapytania GET na coś w XSLT?

Parametry zapytania GET pobierane są w php i wstawiane do

$xml = "<?xml version="1.0"?>
<root>
   <zakladka modul="..." akcja="$_GET['akcja']">
   ...
   </zakladka>
</root>";

Andrew Cohen pisze:
> szomiz pisze:
>> Dopoki nie transformujesz po stronie klienta to co w GET moze ustalac 
>> odpalana transformacje, ktora zainkluduje co wspolne dla wszystkich.
> 
>   Tak, tylko że właśnie sęk w tym, w jakim języku jest "może ustalać". 
> Bo może właśnie chodzi o to, że nie może ustalać, ponieważ już dostaje 
> przetworzone zapytanie GET w postaci XML-a i tego przetworzenia nie może 
> tykać, a co najwyżej może sobie potransformować w XSLT. Przynajmniej ja 
> to tak rozumiem i dlatego pytam o to, w jaki sposób z GET przechodzi się 
> do tego XSLT, żeby przenieść problem dynamicznego importowania szablonów 
> poza XSLT.

Transformacja odbywa się po stronie serwera, język programowania niema 
tutaj najmniejszego znaczenie. Usiłuje znaleźć uniwersalny sposób do 
przetwarzania szablonów xslt na xhtml i to wszystko. Dokładniej pisząc 
chodzi mi o przeważanie szablonów podobnie jak to się dzieje we wzorcu MVC.

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.

szomiz pisze:
> Tykac moze w dowoly sposob. Czasami moze musiec zachowac oryginalne 
> zapytanie (ale wtedy raczej nie GET...) w niezmienionej postaci. To jak 
> roboczo wykorzysta kopie otrzymanych danych jest jego sprawa.
   Przecież jeszcze nic nie było napisane na temat przekształcenia GET do XML.
   Ciekawe, skąd to wywnioskowałeś, że może tykać w dowolny sposób. Wyobraź sobie, że zapytanie GET przychodzi do jednego działu firmy, a ludzie klepiący XSLT siedzą w innym dziale. Dostają XML-a od tych, co obrabiają zapytania GET i nie mają szans wpłynąć w żaden sposób np. na kod PHP, ponieważ koderzy PHP są na nich wkurzeni z powodu pogody.
   Dlatego najpierw ustalmy może, czy mamy szansę wpłynąć na przekształcenie GET do XML, żebyśmy wiedzieli, czy ma sens rozwiązywanie problemu w dziki sposób w XSLT. Bo może da się prościej i łatwiej inaczej.

>> No nie rob se jaj.
> Nawzajem.
   A to jest tylko twoje zdanie.

Użytkownik "Andrew Cohen" <cohen72@o2.pl> napisał w wiadomości 
news:gamb21$l20$1@news.onet.pl...
> szomiz pisze:
>> Tykac moze w dowoly sposob. Czasami moze musiec zachowac oryginalne 
>> zapytanie (ale wtedy raczej nie GET...) w niezmienionej postaci. To jak 
>> roboczo wykorzysta kopie otrzymanych danych jest jego sprawa.
>   Przecież jeszcze nic nie było napisane na temat przekształcenia GET do 
> XML.

Bylo!

>   Ciekawe, skąd to wywnioskowałeś, że może tykać w dowolny sposób.

Chcesz sie klocic, czy pomoc znalezc rozwiazanie?

Wyluzuj.

sz. 

szomiz pisze:
> U?ytkownik "Andrew Cohen" <cohen72@o2.pl> napisa^(3) w wiadomo?ci 
> news:gamb21$l20$1@news.onet.pl...
>>   Przecie? jeszcze nic nie by^(3)o napisane na temat przekszta^(3)cenia GET do 
>> XML.
> 
> Bylo!
   Gdzie?

Użytkownik "Andrew Cohen" <cohen72@o2.pl> napisał w wiadomości 
news:gambtb$nt2$1@news.onet.pl...
>   Gdzie?
Tutaj: <gam9jq$g3o$1@news.onet.pl>
I - sorry - ale dla mnie EOT.
Gdzie, jak gdzie, ale tutaj nie bede sie wdawal w ambicionajnalne pyskowki.

sz. 

szomiz pisze:
> U?ytkownik "Andrew Cohen" <cohen72@o2.pl> napisa^(3) w wiadomo?ci 
> news:gambtb$nt2$1@news.onet.pl...
>>   Gdzie?
> Tutaj: <gam9jq$g3o$1@news.onet.pl>

<gam9jq$g3o$1@news.onet.pl> 20:30
<gam8hb$ai4$2@news.onet.pl> 20:15

   więc nie było wcześniej powiedziane nic na temat przekształcenia GET do XML. A jeśli ja czegoś nie rozumiem, to nie pisz, że EOT i ambicionajnalna pyskówka, tylko mi wytłumacz.

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 )-:

Mariusz S. pisze:
> mhy, przerobić zawsze można, ale myślałem, że można rozwiązać ten 
> problem po stronie szablonu.
   No tak. Tak byłoby najlepiej. Wtedy samo php sprowadzałoby się do przetransformowania GET na XML i odpalenia czegoś w stylu:

xslt::transformacja('szablony/index.xsl', $xml);

> Tworzenie oddzielnych plików xsl dla każdej akcji w module moim zdaniem 
> mija się z sensem.
   A jednak cytujesz takie rzeczy, jak kontakt_dodaj.xsl i kontakt_lista.xsl, ponieważ chcesz pewne rzeczy trzymać osobno. Proponuję coś takiego (mogą być błędy, to tylko koncepcja):

kontakty_dodaj.xsl:

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:import href="modul.xsl" />
<xsl:template mode="abc" match="*">
	<!-- tutaj rzeczy z dodaj -->
</xsl:template>
<xsl:template match="system">
	<xsl:call-template name="strona" /> <!-- ewentualnie z with-param, jeśli trzeba -->
</xsl:template>
</xsl:stylesheet>

modul.xsl:

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:import href="head.xsl" />
<xsl:import href="body.xsl" />
<xsl:template name="strona">
    <html lang="pl">
      <head>
        <xsl:apply-templates select="." mode="Head"/>
      </head>
      <body>
        <xsl:apply-templates select="." mode="Body"/>
      </body>
    </html>
</xsl:template>
</xsl:stylesheet>

fragment body.xsl:
<!-- zamiast choose -->
<xsl:apply-templates select="." mode="abc"/>

   Jednak patrząc z szerszej perspektywy, to Twoje rozwiązanie jest lepsze. Masz na wejściu xml, w którym w zależności od pewnego elementu/atrybutu chcesz wykonać pewne template'y. xsl:choose właśnie do tego służy i to jest poprawne rozwiązanie. Być może chciałbyś zaimportować tylko taki akrusz, z którego rzeczywiście skorzystasz, a nie wszystkie (kontakty_dodaj.xsl, kontakty_lista.xsl). I to jest właśnie to coś, co ja bym rozwiązywał na poziomie PHP. Wybór arkuszu. Ten wybór zależy od parametrów z GET, które i tak przetwarzasz w PHP, więc wybór arkuszu niewiele tutaj miesza, a będzie optymalizacją dla silnika XSLT, który nie będzie musiał przetwarzać tylu plików. Ile to będzie kodu w PHP i co tracisz nie robiąc tego w XSLT?
   A jeśli z jakichś innych powodów bardzo zależy Ci na tym, żeby jednak pewne rzeczy zrobić w XSLT, a nie PHP, to szomiz podał najlepsze i najmocniejsze rozwiązanie:

"Transformacje, przed jej wykonaniem mozesz... stransformowac ;>"

   Będzie to wymagało podwójnej transformacji za każdym razem (przez to wolniejsze), ale będziesz miał swobodę, jakiej chcesz. Oczywiście do momentu, kiedy okaże się, że przydałoby się to 3 razy transformować:)

   Podsumowując wywód: XSLT to nie Lisp. Tutaj nie można wszystkiego.

W obecnej chwili jak projekt jest już dosyć zaawansowany Twoja 
propozycja jest dosyć odważna.

Zastanawiam się jeszcze nad pomysłem szomiz-a - "Transformacje, przed 
jej wykonaniem mozesz... stransformowac ;>", ale nie bardzo mogę sobie 
wyobrazić jak to można oprogramować.

Mariusz S. pisze:
> Zastanawiam się jeszcze nad pomysłem szomiz-a - "Transformacje, przed 
> jej wykonaniem mozesz... stransformowac ;>", ale nie bardzo mogę sobie 
> wyobrazić jak to można oprogramować.

   http://pl2.php.net/manual/pl/function.xslt-process.php

   Przypuszczam, że Example #3 to jest to, ale nie próbowałem. Wynik pierwszej transformacji to byłby u Ciebie plik XSL, który w tym przykładzie jest w zmiennej $xsl, która jest zapamiętana w zmiennej $arguments przed drugą transformacją.
   Trzeba po prostu zrobić tak, żeby do drugiej transformacji arkusz XSL przekazać w zmiennej a nie z pliku.

Mariusz S. wrote:
> Tworzenie oddzielnych plików xsl dla każdej akcji w module moim zdaniem 
> mija się z sensem.

IMO to wygodne. Latwo dodac kolejna akcje. Kazdy taki plik zawiera tylko 
niezbedne dla akcji elementy.


Skoro mozesz tak:
> xslt::transformacja('szablony/'.$dane['modul'].'.xsl', $xml);

To pewnie mozesz i tak (pamietajac o koniecznosci sprawdzenia tego, co w 
$_GET przylezie):
xslt::transformacja('szablony/kontakty'.$_GET['akcja'].'.xsl', $xml);

I teraz kwestia napisania XSLi. Moja koncepcja jest w zasadzie zbiezna z 
tym, co proponowal Andrew Cohen, przy czym:
- szablony nazwane nie sa potrzebne w takich przypadkach (IMO)
- sprobowalem pokazac bardza fajna ceche importu - czyli nadpisywanie 
szablonow.

========================================
modul.xsl (tu sa generowane elementy wspolne dla wszystkich widokow)
========================================
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

   <xsl:template match="/">
     <html>
       <head>
          ...
       </head>
       <body>
         <xsl:apply-templates select="zakladka"/>
       </body>
     </html>
   </xsl:template>

   <xsl:template match="zakladka">
     <!-- Szablon "abstrakcyjny", mogloby go wogole nie byc
          - i tak zostanie nadpisany :-) -->
   </xsl:template>

</xsl:stylesheet>

========================================
kontakty_lista.xsl (tu tylko to co dla listy)
========================================
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

   <xsl:import href="modul.xsl"/>

   <xsl:template match="zakladka">
     <!-- Wyswietlamy liste -->
   </xsl:template>

</xsl:stylesheet>

========================================
kontakty_dodaj.xsl (tu tylko formularz)
========================================
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

   <xsl:import href="modul.xsl"/>

   <xsl:template match="zakladka">
     <!-- Wyswietlamy formularz -->
   </xsl:template>

</xsl:stylesheet>

-- 
NotBear

> I teraz kwestia napisania XSLi. Moja koncepcja jest w zasadzie zbiezna z 
> tym, co proponowal Andrew Cohen, przy czym:
> - szablony nazwane nie sa potrzebne w takich przypadkach (IMO)
> - sprobowalem pokazac bardza fajna ceche importu - czyli nadpisywanie 
> szablonow.

Bardzo interesujące rozwiązanie myślę, że warto się nad tym zastanowić.

Dziękuję wszystkim zainteresowanym za pomoc (-:

--
Pozdrawiam
Mariusz