nicht angemeldet
Hi
also ersteinmal danke für die sehr Ausführliche Antwort!!
habe etwas gebraucht um alles verarbeiten ;-)
Der mächtigste Teil von XSLT sind die XPath-Ausrücke. Ein guter XSLT-Editor hat auch einen XPath-Parser. Das erleichter die Arbeit ungemein und hilft sehr viele Fehler von vornherein zu vermeiden.
Bei einem Ausdruck wie z.B.
match="subpage[not(@cmsused = 'no') and (publish = 'yes') and (number(concat(substring(/data/dateandtime/date,1,4),substring(/data/dateandtime/date,6,2),substring(/data/dateandtime/date,9,2))) >= number(concat(substring(startdate,1,4),substring(startdate,6,2),substring(startdate,9,2))))]"oder
href="Walker?source={sdml:getPathFromIndex($pagenode/id(@idref)/preceding-sibling::document[last()], $pagenode/id(@idref)/preceding-sibling::document[last()], '')}&style={sdml:getXSLPage($pagenode/id(@idref)/preceding-sibling::document[last()]/@id)}"
kann man schnell einen Fehler machen, nicht nur wenn man sich vertippt, sondern auch was den korrekten Inhaltstyp des Ausdrucks angeht.
Hier hilft Eclipse gar nicht. Macht man einen Fehler wird das erst sichbar wenn man dein XML dann transformiert (und dann darf man in den serverlogs nachsehen, ob da eine gute Fehlermeldung steht)
Ein Editor mit einem XPath-Parser zeigt aber schon hier Tippfehler und mögliche Typ-Unverträglichkeiten an.
gibt es da auch nur XPath editoren, in die man so einen pfad einfach reinkopieren könnte.?
Du kannst ja in die XSLT-DTD die HTML-DTD integrieren:
<!ENTITY % html.dtd SYSTEM "html.dtd">
%html.dtd;und dann die in der XSL-DTD bereist definierte Entities verwenden:
<!ENTITY % result-elements "html">
<!ENTITY % non-xsl-instructions "html">Aber wenn du dann z.B. nicht HTML sondern (XSL-)FO als ausgabe haben willst, muss du das austauschen. Und wenn du auch SVG erzeugen willst, auch. Und wenn du [setze was ein] erzeugen willst, auch.
Oder es so machen:
<!ENTITY % result-elements "(html | svg:svg | xsl:fo)*"> und so weiter.
Und dann würdest du DTDs für SVG, XSL-FO etc. brauchen.
Habe ich ausprobiert, aber es gab das Problem, dass man ja von jedem neuen Knoten aus wieder alle xsl-elemente aufrufen können muß.
habe aber in der datei den template-knoten als Vorbild genommen und muß nun alle elemente doch direkt in die dtd einfügen. ich denke das ist eine gute übung. immer wenn ich ein Element brauche, werde ich es einfügen.
Was meinst du mit "so einer xml datei"? Aus einer wo XML und XSLT in wildem Miteinander mit HTML föhlich eine Regen des Willkürs und der Unübersichtlichkeit tanzen?
man würde halt nach jedem einleitenden Tag für ein element auch noch das xsl stylesheet mitgeben
so vielleicht ;-)Daten:basis
<xsl:template match="?">
</xsl:template>Daten:node
<xsl:templa...
</ xsl:templ...</ inhalt:basis>
Wäähhh! Iggit! ;-)
findest du? ;-) zumindest wären die xml - xsl Beziehungen ganz übersichtlich.
..habe da ja auch noch keine Erfahrung..
vielleicht ,wenn das Layout sowieso aus einem rahmen-Layout besteht, in das dann weitere xml-xsl-dateien als Inhalt eingefügt werden,..vielleicht benötigt man diese übersichtlichkeit gar nicht so.
wie ist das eigentlich wenn man apply-templates aufruft und es gibt kein weiters template ? : -> ist das ein Problem?? naja ich werde es ja herausfinden, wenn ich es ausprobiere.
Natürlich kannst du dann in PHP Funktionen schreiben, die dir aus dem einen DOM-Objekt zwei erstellt und dann jeden für sich mit XSLT zu jeweils andere XHTML-Datei transformiert. Aber da muss du dir auch überlegen, dass z.B. an den Browser immer nur eine Datei zur selben Zeit gesendet werden kann, also wirs du die Ergebnisse der Transformationen auf die Platte schreiben müssen. etc. Oder eben umgekehrt, aus zwei DOM-Objekten eines erstellt und nur dieses transformiert.
werde wohl ersteinaml den xslt parser in php benutzen und der gibt ja nur eine xhtml datei aus .
mal sehen ob ich dann jetzt meine erste xml xsl seite hinbekomme.;-)
danke nocheinmal für die Tips
grüße .. & ;_)
carsten