nicht angemeldet
Hi,
Aber ein Problem habe ich nocht immer mit deinem Ansatz: mir fehlt noch der genaue Verständnis dazu, was du in diesem Zusammenhang von einem Tool/Programm erwartest. Es gibt kein Programm, das dir ein XSLT-Sheet schreibt, sie alle bieten dir nur dabei Unterstützung an.
Was du dann mit der fertigen XSL-Sheet machst ist eine andere Frage, da kannst du natürlich sagen, dass auf ein aus der DB generiertes XML dein XSLT angewendet werden soll.Vielleicht reden wir hier aneinander vorbei?
bestimmt, oder vielleicht doch nicht? ;-)
Hmja, also Mitte der Neunziger hatte ich fuer einige Jahre das Vergnuegen mit "VB" einige Projekte umzusetzen. Die Sache lief ganz gut, dank 'RAD' ((R)apid A(<irgendwas>) (D)evelopment). Kaum wartbare, schlecht skalierbare und nicht weiterentwickelbare Systeme kamen da heraus. (Die Abnehmer waren aber im Grossen und ganzen nicht unzufrieden.)
Man hantierte da mit Datenbindung, was damals bedeutete irgendwelche "Steuerelemente" an Datensatzmengen zu binden, die als Prototyp zur Entwurfszeit geladen wurden.
Nun schreiben wir das Jahr 2004. Aus Datensaetzen sind Datensatzmengen geworden und aus diesen "Dokumente" (oder gibt es bessere Woerter?). - Da ich dem 'RAD'-Ansatz gar nicht mal so skeptisch gegenueberstehe (vorausgesetzt, dass mindestens ein Entwickler noch weiss, was wirklich passiert), habe ich meine Erfahrungen einfach mal ins Jahr 2004 projiziert. Das 'RAD'-Tool, das ich erwarte, wuerde halt als Datenquelle ein XML erwarten und ansonsten die normale "Frontpage"-Funktionalitaet (".NET"-Studio von mir aus) bieten.
Dank XML(TM) koennte sogar etwas vernuenftiges dabei herauskommen.
Ich werde in den naechsten Wochen 'XML Spy 2004 E.' aufmerksam auf Leistungsmerkmale der o.g. Art testen. Vielleicht gibt's aber noch andere "Tools"?
Gruss,
Lude
---
"Realitaet ist das, was noch da ist, wenn man aufgehoert hat zu gleuben."