🚀 go-pugleaf

> >W każdym razie może jakieś konkretne argumenty za tym że pierwsze jest
> >szybsze???
>
> Cóż, pierwsze rozwiązanie to tylko przekopiowanie na wyjście elementu.
> Drugie wymaga utworzenia znacznie większej struktury.

to fakt, że plik utworzony wg drugiej metody jest obrzydliwie wielki...

> >a dlaczego mam nadal wątpliwości?
> >otóż wydaje mi się że parser xml/xsl/xslt powinien być najszybszy
> >w przetwarzaniu "natywnych" poleceń związanych bezpośrednio z xsl/xslt...
>
> Elementy inne niż <xsl:foo> też są natywne, co więcej ich się w ogóle nie
> przetwarza, tylko dołącza do struktury wyjściowej.

ok, powoli zaczynam przyjmować to do wiadomości - jednak jak bym to zobaczył
napisane w jakiejś dokumentacji to był bym w pełni zadowolony - może siakiś
link ?

> >a żeby się niektórym nie wydwało że bredzę to podam przykład gdzie lepiej
> >stosować teoretycznie powolne rozwiązania... chodzi mi mianowicie o asp.
> >
> >Wszędzie w poradnikach microsoftu piszą że jak się już musi wygenerować
tag
> >html
> >w ciągu wykonywania się skryptu asp to lepiej to zrobić
> >używając dhtml'a (co jest teoretycznie powolne)
> >niż wychodzić ze skrytpu asp i wstawiać fragment html,
> >po prostu kompilator więcej czasu zużywa na przerwanie wykonywania asp i
> >"łyknięcie" taga html niż utworzenie go ze skryptu.
> >
> >stąd właśnie zastanawiam się czy tu nie zachodzi podobna analogia...
>
> Myślę, że analogia jest zła. Niedoróbka MS nie musi dotyczyć parserów.

no nie wiem czy to dotyczy tylko MS - o ile wiem to skrypty w php też zaleca
się pisać blokami jak najmniej mieszając - co oczywiście jest dozwolone ale
nie jest polecane...

> A nie możesz po prostu przetestować i to tego procesora XSLT, którego
> będziesz używał?

tia, chciałbym i owszem ale jak? - znasz jakiś software do mierzenia
wydajności?
witryna napisana w asp - > xml/xslt po stronie serwera a serwer to IIS 5.0 ,
parser MSXML 3.0, system to oczywiście Win y2k, choć planuję również php,
sablotron i apache...

Marcin