Rozumim tomu co pisete, ja s tim souhlasim. Obecne to tak je. Ale jak jsem psal, u me je to hodne specificky priklad. XSD se nemeni za behu aplikace. Jsou pevne dane pred spustenim aplikace. Postup je takovy, ze uzivatel nahraje potrebna XSD do daneho adresare. Potom spusti aplikaci. Aplikace si tato XSD nahraje a pomoci XSOMu naparsuje. Pomoci XSOMu je schopna zjistit informace z anotaci...
Data vim kam budu vyplnovat. U kazdeho elementu mam anotaci ktera obsahuje key, identifikator toho jakou hodnotu tam mam vlozit. Takze jak jsem psal, tak asi jedinym zpusobem ktery me napadl je projit objektovou reprezentaci XSD a vytvaret XML message. Tam kde narazim na element s anotaci tak tam vlozim podle zadaneho key hodnotu. Tuto message pak poslu. V podstate jak asi spravne pisete tak jiny zpusob ani neni mozny.. Je to velice specificke XSD. Mozna jsem mel rict ze XSD je vytvareno XSD designerem treti strany. Tento designer neumoznuje vytvorit jinou strukturu XSD nez ktera je pozadovana aplikaci. Tzn. jeden complexType se sequenci ktera obsahuje elementy ruznych typu. Diky za pripominky a navrhy 2011/4/19 Petr Novak <[email protected]> > > Stejně asi jako ostatní si myslím, že to, co chcete vytvořit je tak trochu > nesmysl. Možná to bude fungovat ve velmi omezené podobě na drobné změny v > xsd, ale i to, že žádná podobná knihovna asi vůbec neexistuje svědčí o tom, > že takto se tato problematika neřeší. > To budete psát parser s umělou inteligencí, který umí odpovídat na > jakýkoliv dotaz - ty příklady se slovenštinou byly přesný :) . Jak už tu > bylo několikrát uvedeno, těžko můžete vyplňovat data, která ani nevíte kam > budete vyplňovat, případně, když po Vás XSD bude vyžadovat nové položky, tak > to byste pak k tomu musel dynamicky dogenerovat i nějakou logiku v aplikaci, > která by je vypočítala a doplnila a nebo to napojit na křišťálovou kouli :). > > Nevím jak často a jak moc se Vám ta XSD mění a kdo je jejich dodavatelem > (jestli to je v rámci projektu, nebo externě). Ale z principu věci pokud > Vám někdo mění to XSD - tedy vzdálené rozhraní, tak buď musí dělat > kompatibilní změny, pak vy nemusíte nic měnit a nepotřebujete dynamické > generování XML, protože to Vaše naimplementované bude stále validní. A nebo > dělá nekompatibilní změny a pak vy musíte vytvořit novou knihovnu na základě > nového XSD - standardní Change-Request-management. Pak by ty XSD měly být > verzované, atd.. Navíc, pokud ta změna bude až takového rázu, že tam > přibude třeba datový element navíc, tak to stejně může znamenat, že musíte > upravit dotazy do DB, apod. abyste ty data vůbec získal a mohl je vložit do > XML. > > Vždy když slyším podobný požadavek od svých kolegů, tak jim vysvětlím, co > je to API a XSD je API a všem, co něco takového navrhují doporučuji > nastudovat http://wiki.apidesign.org/wiki/Main_Page a především celou tu > knížku Jardy Tulacha, a je úplně jedno, že to není o XSD, protože principy > jsou stále stejné. Ale chápu, že jste možná v situaci, kdy Vám to API > dodává třetí strana, která neumí držet zpětnou kompatibilitu a neustále něco > mění - pak jsou jen 2 řešení - buď změnit dodavatele a nebo udělat > mezivrstvu, která bude tuto nekompatibilitu řešit. I o tom je v té knize > povídáno - řešení závislostí na třetích stranách. > > Proto se asi v těchto případech používají různé integrační servery, ESB, > apod. - vlastně tvoří tu mezivrstvu. A tak mě napadá, že tím se můžete i > inspirovat a použít XSL. > > Udělat to více volně vázané, tedy vy budete generovat nějaké své statické > XML, které budete přes XSL transformovat na to požadované XML odpovídající > tomu XSD. Ale ani to XSL nedokážete asi generovat dynamicky podle XSD. Ale > mělo by to výhodu v tom, že nemusíte programovat, kompilovat, deployovat, > apod. Prostě jen budete měnit transformační šablony umístěné v adresáři > mimo. > > A nebo ještě mě napadlo použít šablony na generování toho XML z dat - > tedy třeba vzít freemarker, nebo velocity - udělat si v něm šablonu XML > elementů (prostě šablonu té message) a na patřičná místa doplňovat jen > hodnoty. A když se změní API v podobě změny XSD, tak hold musí někdo > sednout a ty šablony upravit pro tu novou verzi. A opět se nemusí řešit > žádná kompilace, apod. Prostě jen nahrajete nová XSD, upravíte šablonu, > vygenerujete si zkušební XML, proženete ho přes XSD validator, tím ověříte, > že vše je OK, že šablona generuje správná XML, která pak můžete v klidu > posílat dál do fronty. > > A nebo použít nějaký dynamický jazyk a skládat to jako DOM mimo javu, aby > ty změny byly jednodušeji zapracovatelné - groovy, ruby, apod. Vlastně je to > podobné těm šablonám, jen jiný způsob. > > Tak snad to dá zase trochu jiný pohled na Váš problém ... > > > > Dne 19.4.2011 15:27, Vladislav Krejčiřík napsal(a): > > Aplikace funguje nasledovne: > > Pri startu si aplikace natahne vsechny XSD ze zadaneho adresare. Pak > potrebuju ke kazde XSD definici udelat validni XML message do ni vlozit > potrebne hodnoty a poslat na zadanou queue. > > XSD definice ktere slouzi jako vstup jsou znacne omezene. Obsahuji jen > jeden ComplexType se sequenci elementu ruznych typu. Ale chapu ze tohle je > specialni pripad a obecne to jiste nelze.. > > > Postup vyuziti xjc pro vygenerovani pomocnych trid neni podle me v mem > pripade vhodny.. Situace je velice podobna pripadu, kdyz by se XSD menily za > behu. > > Je nejaky obecny postup sestavovani validnich XML message z dynamicky se > menicich XSD? > > Dekuji za vase nazory. > > > XSD muze vypadat takto: > > <?xml version="1.0" encoding="ibm852"?> > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";> > <xs:complexType name="L1_L2_CyclicDataRM"> > <xs:annotation> > <xs:appinfo> > <Transport>EMS</Transport> > <MessageType>Queue</MessageType> > <MessageName>ems.topic.L1_L2_CyclicDataRM</MessageName> > <Timer>2000</Timer> > </xs:appinfo> > </xs:annotation> > <xs:sequence> > <xs:element name="Bucket__Brigade"> > <xs:complexType> > <xs:sequence> > <xs:element maxOccurs="unbounded" name="ArrayOfString" > type="xs:string"> > <xs:annotation> > <xs:documentation>Bucket > Brigade.ArrayOfString</xs:documentation> > </xs:annotation> > </xs:element> > <xs:element name="UInt2" type="xs:unsignedShort"> > <xs:annotation> > <xs:documentation>Bucket Brigade.UInt2</xs:documentation> > </xs:annotation> > </xs:element> > <xs:element name="Boolean" type="xs:boolean"> > <xs:annotation> > <xs:documentation>Bucket Brigade.Boolean</xs:documentation> > </xs:annotation> > </xs:element> > <xs:element name="Int1" type="xs:string"> > <xs:annotation> > <xs:documentation>Bucket Brigade.Int1</xs:documentation> > </xs:annotation> > </xs:element> > </xs:sequence> > </xs:complexType> > </xs:element> > <xs:element name="Square__Waves"> > <xs:complexType> > <xs:sequence> > <xs:element name="UInt1" type="xs:byte"> > <xs:annotation> > <xs:documentation>Square Waves.UInt1</xs:documentation> > </xs:annotation> > </xs:element> > <xs:element name="Real8" type="xs:double"> > <xs:annotation> > <xs:documentation>Square Waves.Real8</xs:documentation> > </xs:annotation> > </xs:element> > <xs:element name="Int2" type="xs:short"> > <xs:annotation> > <xs:documentation>Square Waves.Int2</xs:documentation> > </xs:annotation> > </xs:element> > </xs:sequence> > </xs:complexType> > </xs:element> > </xs:sequence> > </xs:complexType> > </xs:schema> > > > > > > 2011/4/19 Robert Novotny <[email protected]> > >> Vezmime si priklad zo slovenciny. Mam gramatiku, ktora hovori, ze >> slovenska veta ma mat: >> >> Podmet - prisudok - predmet. >> >> Validacia sa pyta, ci veta ,,Pes zerie granule" splna gramatiku. Vy vsak >> chcete riesit problem typu ,,potrebujem vyrobit slovensku vetu". Ako ma >> kniznica vediet, ci ma vygenerovat slovensku vetu ,,Pes zerie granule" alebo >> ,,Vyvojar miluje Javu" alebo ,,Ja mam psa"? >> >> Ako sa spominalo, JAXB na zaklade XSD vyrobi triedu s instancnymi >> premennymi podmet, prisudok, predmet a anotaciami zaisti, ze objekt sa >> serializuje spravne a teda ze vysledne XML bude splnat schemu. >> >> Ako nad tym uvazujem, tak bud chcete mat v kode obmedzene, aby ste >> nevymysleli nahodou spravu, ktora nedava zmysel (,,Vonku prsi"), lenze to >> vam zaisti prave typovy system, ktory je reprezentovany prave triedami, >> ktore su vygenerovane v JAXB. >> >> Vy hovorite, ze nechcete generovat ziadne triedy ,,ukladane na >> filesystem", ale mne to nie je jasne. Typicky workflow znamena, ze mam XSD, >> v kompilacnom kroku z neho vypadnu klasicke Java triedy a tie pouzivam uplne >> rovnako ako akekolvek ine triedy. Alebo mate situaciu, ked sa XSD meni za >> behu? >> >> RN >> >> >> >> On 19. 4. 2011 14:11, Vladislav Krejčiřík wrote: >> >> ok, mozna jsem to spatne popsal. Zkusim znovu. Ja nechci nic validovat, >> protoze nemam vlastne ani co. XSD mi definuje strukturu nejake message. Ja >> bych potreboval takovou messge umet vytvorit, "vygenerovat" z XSD definice. >> Myslel jsem ze bych ziskal nejakou objektovou reprezentaci te XML message >> kde bych nastrkal hodnoty co potrebuju. Potom bych uz jen XML message poslal >> do fronty. >> >> Nevim jestli existuje nejaka knihovna, ktera to umoznuje. Nebo budu >> muset rucne takovou XML vystavet.. >> >> >> >> >> >> Dne 19. dubna 2011 12:48 Lukas "lzap" Zapletal >> <[email protected]>napsal(a): >> >>> Vlado, >>> >>> myslim ze se tady snazis michat dve veci. DOM a XSD. Prvni jmenovany >>> slouzi >>> k manupulaci s (ted to zjednodusim) XML, druhy je urcen pro popis a >>> kontrolu >>> XML dokumentu. Krome jineho lze namapovat na JavaBeany a ruzne jine >>> struktury zname z pocitacovych jazyku. >>> >>> To co asi chces je nejprve dokument zvalidovat pomoci XSD schematu >>> (doporucuji ruzne tutorialy na netu), a pote jej proste a jednoudse >>> nacist >>> do DOMu a parsovat. Je mozne, ze nejaka DOM knihovna to bude umet udelat >>> "v >>> jednom", ale v podstate jsou to dve ruzne veci. >>> >>> Nebo jsem te mozna spatne pochopil. Zkus to reformulovat. >>> >>> http://en.wikipedia.org/wiki/Document_Object_Model >>> http://en.wikipedia.org/wiki/XML_Schema_(W3C) >>> >>> >>> ----- >>> Later, >>> Lukas >>> -- >>> View this message in context: >>> http://konference-java-cz.958153.n3.nabble.com/Vytvoreni-instance-XML-objektu-z-XSD-definice-tp2837707p2838272.html >>> Sent from the konference java.cz mailing list archive at Nabble.com. >>> >> >> >> >> -- >> >> /**************************************/ >> Best regards / S pozdravem >> Vladislav Krejčiřík >> http://www.vkrejcirik.info >> >> >> >> > > > -- > > /**************************************/ > Best regards / S pozdravem > Vladislav Krejčiřík > http://www.vkrejcirik.info > > > > > -- > Petr > > -- /**************************************/ Best regards / S pozdravem Vladislav Krejčiřík http://www.vkrejcirik.info
