XSLT och CSS för att visa XML. Använd inte specialtecken
De vanligaste sätten att konvertera ett XML-dokument till användarens visad visning är:
Stilapplikation CSS.;
Ansökan Xsl;
Skriva på något programmeringsspråk i XML-dokumenthanteraren.
Utan med hjälp av CSS. eller Xsl XML-dokumentet visas som en enkel text i de flesta webbläsare. Vissa webbläsare som Internet Explorer. och Mozilla Firefox. Visar dokumentets struktur i form av ett träd, så att du kan vika och distribuera noder med hjälp av muskeltrockerna.
Tillämpning av CSS-stilar.
Processen liknar applicering CSS. till Html- Dokument för visning.
För cSS-applikationer När du visar i webbläsaren måste XML-dokumentet innehålla en speciell hänvisning till stilarket. Till exempel:
href.\u003d "Mystylheet.css"?\u003e
Det skiljer sig från HTML-tillvägagångssättet, där elementet används. .
Applikation XSL.
Xsl Han är en familj av rekommendationer som beskriver omvandlings- och visualiseringsspråk i XML-dokument. Dokumentet omvandlas till ett format som är lämpligt för visning i webbläsaren. Webbläsare - det här är det mesta frekvent användning XslMen glöm inte att du använder XSL du kan omvandla XML till något format, till exempel Vrml, Pdf., text.
För uppgift Xsl transformation ( Xslt) Följande typ av instruktioner krävs på klientsidan:
XML-ordböcker
Eftersom XML är ett ganska abstrakt språk, utvecklades XML-ordböcker.
Ordlistan tillåter utvecklare att komma överens om lite begränsat uppsättning taggnamn och attribut av dessa taggar. En av de första ordböckerna är XhtmlVem förstår de flesta webbläsare. XHTML används ofta för att lagra och redigera innehåll i CMS..
Fler specialiserade ordböcker skapades, till exempel dataöverföringsprotokoll TVÅL.Vilket är inte mänskligt orienterat och ganska svårt att läsa. Det finns kommersiella ordböcker, som COMMERCEML., xcbl och cxml Som används för att överföra dataorienterade data, innehåller dessa ordböcker en beskrivning av beställningssystemet, leverantörerna, produkterna och så vidare.
Vanligtvis, som beskriver något dokument, kommer en person för sig själv med någon ordlista, som sedan beskrivs av DTD. Eller helt enkelt förklarar "på fingrarna" till berörda parter.
En av de ordböcker som mottas utbredd är FB2. - Ordbok som beskriver formatet för boken, med alla slags fotnoter, citat, jämnt bilder.
Hur ser ett XML-dokument ut?
Om du är bekant med HTML, kommer studien av XML inte att kräva mycket ansträngning från dig. Även om XML definitivt är väldigt annorlunda i sina möjligheter och syfte från språket i hypertextmarkering, är båda dessa språk delmängder sGML, och därmed ärva sina grundläggande principer.
Dokumentstruktur
Det enklaste XML-dokumentet kan se ut så här visas i exempel 1
Också, som i HTML, heter instruktioner som är inneslutna i vinkelfästen taggar och tjänar till att markera huvudtexten i dokumentet. I XML finns det öppnings-, stängnings- och tomma taggar (i HTML, existerar konceptet av en tom etikett, men ingen speciell beteckning krävs).
XML-dokumentkroppen består av märkningselement (markup) och direkt innehållet i data dokumentet (innehåll). XML-taggar är utformade för att bestämma elementen i dokumentet, deras attribut och andra språkdesigner. Vi kommer att prata om vilka typer av applicerade i dokumenten av markeringen mer detaljerat senare.
Alla XML-dokument måste alltid börja med instruktionerna., inuti som du också kan ange numret på språkversionen, kodsidans nummer och andra parametrar som krävs av analysatorprogrammet under dokumentets parsing
Hur man använder XML
XML som ett verktyg
Används ofta förkortningar
- CDATA: Karaktärsdata (symboliska data)
- DOM: Dokumentobjekt. Modell ( objektmodell dokumentera)
- E4X: Ecmascript för XML (Ecmascript för XML)
- IDE: Integrerad utvecklingsmiljö (integrerad utvecklingsmiljö)
- W3C: Världen. Bred webb. Konsortium (www consortium)
- XML: Extensible Markup Language (Expanderbart Markup Language)
- XSLT: Extensible Stylesheet Language Transforms (Expanderbart språk av stil tabell översättningar)
För närvarande uppfattas XML som något av beviljat. Han är överallt! Men om du tittar från sidan kan du se att det här är en kraftfull teknik. Det finns integrerade utvecklingsmiljöer som hjälper till att bygga XML-träd. Det finns ett antal XML-kodverifieringsteknik. Det finns XSLT - Special Språk xML-transform. XML-stöd är inbyggt även direkt i syntaxen på vissa språk (t.ex. E4x i ActionScript).
Men XML har och baksida. Den kan användas felaktigt. Det kan användas dåligt. Det kan vara alltför komplicerat. Det kan vara oskyddat. Med det kan vara svårt att arbeta. Vad ska man göra för mer effektiv användning Den här kraftfulla tekniken? I min artikel kommer jag att ge 10 tips för att hjälpa till att svara på den här frågan.
Använd inte XML som filnamn eller root-tagg
Många gånger har jag sett en XML-kod som är lagrad i filer med Extension.xml. Det är meningslöst. En sådan förlängning kommer inte att berätta någonting som jag inte skulle veta, helt enkelt genom att köra CAT-kommandot. Så snart jag ser taggar förstår jag omedelbart att det här är XML. I stället för den här förlängningen, använd en förlängning som är meningsfull för användaren. Du kan också använda en unik förlängning så att när du söker efter Google returnerade du länkar till dokumentation eller på exempel på ditt XML-filformat.
Ett annat problem i vissa XML-dokument är användningen av root-tagg
Överväg inte generaliserad eller specifik design
Jag förstår att XML är ett format för att spara data. På de flesta språk ger ett sätt att spara datastrukturer i XML. Tja, om du är säker på att endast de processer som skrivs på samma språk någonsin kommer att läsa eller skriva din XML-kod. Detta är dock sällsynt. Om din ansökan skriver något till en fil, är det troligt att användaren vid något tillfälle läser den eller någon applikation på ett annat språk.
Detta vill jag säga att den strukturspecifika designen behöver lagras utanför XML. Hur ofta träffades du 07-18-2010 ? Vad är NSDATE? Ja, det här är klassens namn att arbeta med datum på applikationsplattformen. Vad händer när du byter plattform eller språk? Du måste konvertera NSDate-taggar till något annat, som används på en ny plattform.
Spara specifikationer för språket utanför XML och använd enkla taggar, säg
Annan en viktig regel - Undvik användning i XML onödiga generaliseringar. Ta en titt ytterligare exempel ():
Notering 1. Allmänna noder träd
Vad betyder det här? Jag insåg att det här är en lista över användare. Men det är svårt för en person att läsa och redigera. Ännu värre, denna XML-kod är mycket svår att använda på medel som XSLT, eller kontrollera dess korrekthet med hjälp av schemat. Det visas att faktiskt betyder ovanstående XML-kod.
Lista 2. Effektiva noder träd
Är det inte bättre? Koden säger vad betyder och betyder vad han säger. Det är lättare att läsa och analysera. Det är lättare att kontrollera och konvertera med XSLT. Det är ännu mindre i storlek.
Gör inte filer för stora
Vet vad du säger: " Diskminne Det är billigt. För tio cent kommer jag att köpa en annan terabyte. "Det här är sant. Du kan verkligen skapa Gigabyte XML-filer. Men programmering är konstanta kompromisser. Du måste byta disk utrymme För en tid eller ett minne ett tag. Och när du arbetar med en stor XML-fil får du de värsta sidorna och den andra. Filen tar mycket utrymme på disken, och det finns lång tid för sin analys och check. Dessutom, stor fil Eliminerar användningen av DOM-analysatorn, eftersom byggandet av ett träd kräver oändlig tid och stort antal Minne.
Vad är samma alternativ? Du kan skapa flera filer. En fungerar som ett index, medan andra innehåller stora resurser som kan behövas inte till alla användare av denna XML. Ett annat alternativ är att avlägsna alla stora CDATA-fragment från XML-filen och placera dem i deras egna filer med egna format. Om du vill lagra alla data tillsammans, vrid alla filer i ny fil. Med ny expansion. Alla populära programmeringsspråk har moduler som underlättar snabba förpackningar och uppackningsfiler.
Använd inte namnområden, om det inte finns något skarpt behov
Namespace (Namespace) är en kraftfull komponent i XML Lexicon. De underlättar genomförandet av expanderbara filformat. Du kan bestämma grunduppsättning Taggar för alla behov av din ansökan, och tillåter sedan användare att lägga till egna data till din egen namnrymd i filen utan att påverka dina trädobjekt.
Men namnområden är mycket svåra syntaktisk analys och datahantering. De förvirrar expansionen av programmeringsspråk, såsom E4x. De gör det svårt att använda XML i XSLT. Slutligen gör de XML-filer mycket svårare att läsa.
Använd därför XML Namespaces endast om det verkligen är nödvändigt. Använd inte dem helt enkelt för att "XML låter dig göra det." XML fungerar perfekt utan namnområden.
Använd inte specialtecken
Alla mina tips syftar till att upprätthålla renhet, enkelhet och lätthet av att uppleva din XML-kod. I den meningen tillåter även XML-specifikationen mycket, vilket är väldigt valfritt att använda. Till exempel, i namnen på element och attribut, kan du använda ett streck. Men det här gör det svårt att använda en sådan XML-kod i språkförlängningar, till exempel i E4X. Frågan är om?
Använd XML Schema.
XML-syntaxanalys är en svår uppgift. För noggrann analys är det nödvändigt att göra ett bra jobb att skydda koden från möjlig frånvaro och felaktig användning av taggar eller attribut. Det extraarbete Genom att skriva kod, ytterligare komplexitet, liksom skuggningen av verklig affärslogik, vilket är ditt huvudsakliga problem. Hur man undviker detta? Kontrollera XML innan Dess användning. För att göra detta kan du använda flera standarder. Du kan ange DEFINITY DEFINITY (DTD) eller XML Schema. (Länkar till information om DTD och XML Schema visas i avsnittet). Personligen hittar jag XML-scheman mycket enklare i ditt arbete, men om du är ny i det här fallet, prova olika korrekthetskontrollsystem.
En stor fördel är att efter att ha kontrollerat XML: s korrekthet kan det vara säkert. Kanske är det inte nödvändigt för de interna XML-filerna i din ansökan. Men det är mycket användbart om XML genereras av en annan applikation eller skrivs manuellt.
Namnversion
Det är väldigt lätt att missa det faktum att XML som är lagrade i filer motsvarar filformatet. Det första som innehåller en fil med något format är versionsnumret. Det är lätt att lägga till:
Kombinera noder och attribut
Ingenjörer är ganska lata människor. Jag kan argumentera för det eftersom det själv är. Argumentera inte, vi är alla. Om den integrerade utvecklingsmiljön erbjuds att utföra exporten av XML istället för oss, kommer vi förmodligen att komma överens. Men brukar den integrerade miljön skapa en mycket dålig XML-kod. Förmodligen har du redan träffat något som:
Listning 3. Användarlista
Bör ligga
För att koden ska läsas är det utan tvekan bättre att använda attribut som visas.
Notering 4. Mer bekväm lista över användare
Det är uppenbart att det integrerade mediet genereras, eftersom det alltid är säkrare att använda noder. Men attribut tillåter dig att identifiera viktiga saker i DOM-trädet, så de ska användas.
Använd CDATA, men missbruk inte
XML lägger många begränsningar för användningen av vissa tecken: citat, ampersands, "mindre" och "mer" tecken, etc. Men i praktiken används dessa tecken mycket ofta. Därför är det nödvändigt att antingen konvertera allt till ett säkert format säkert för XML, eller placera stora textfragment, kod eller något annat till CDATA-blocken. Det verkar för mig att utvecklarna undviker att använda CDATA, eftersom de tror att det kommer att göra det svårt att syntaktisk analys. Men CDATA-sektionerna är inte svårare att analysera än någonting annat - de flesta DOM-analysatorer hanterar dem självständigt, så du behöver inte ens tänka på det.
En annan viktig anledning att använda CDATA är att bevara exakt dataformatering. Till exempel, när du exporterar en Wiki-sida, vill du förmodligen spara positionerna för sådana tecken som att återvända vagnen och rad översättningen, eftersom de spelar en särskild roll i Wiki-formatet.
Varför inte använda CDATA-sektioner ständigt? Eftersom de kraftigt gör det svårt att läsa dokumentet. Detta är särskilt obehagligt när de inte behöver. Så, använd dem och uppmuntra dem att använda användare av dina XML-filer i de situationer där data, enligt din åsikt, kommer att innehålla särskilda symboler Och när du behöver spara den ursprungliga formateringen. Men använd inte CDATA i andra situationer.
Håll valfri data i ett separat område
Hittills talade jag om XML-dokument med ett hårt format. Jag rekommenderade även med hjälp av korrekthetskontrollteknik (till exempel XML-schema), vilket garanterar en styv struktur. Det är bra anledning: Strukturerade data är lättare att analysera. Och om du behöver en viss flexibilitet? Jag rekommenderar att du placerar valfri data i ett separat block i din egen nod. Ta en titt, till exempel på.
Notering 5. Unordered användarpost
Denna post innehåller alla förväntade användardata. Jag håller med först, mitten, sist, men varför är Runepace? Det är nödvändigt? Har du många sådana områden? Kommer de att expandera? Om svaret på alla dessa frågor är jakande, skulle jag rekommendera att göra det (se):
Notering 6. Välstrukturerad användarrekord
Med detta tillvägagångssätt kan du ha några områden, inte klamrar på moderelementets namnrymd
Slutsats
Tänk på vad jag sa. Jag rekommenderade fem saker värda att göra, och fem saker att undvika. Inte alla mina tips är tillämpliga under inga omständigheter. Ibland är XML bara ett datalagringsformat som sänds över nätverket och livliga bara några millisekunder. I det här fallet bör du inte bry sig om någonting. Men när du använder XML som filformat, bör du lyssna på mitt råd och tillämpa rekommendationerna här.
Standarden definierar två nivåer i XML-dokumentet:
- Korrekt byggd (Välformad). Korrekt byggt dokument uppfyller alla generella regler XML-syntax som är tillämplig på ett XML-dokument. Och om till exempel den ursprungliga taggen inte har den slutliga taggen som motsvarar den, då detta felaktigt byggd XML-dokument. Ett dokument som är felaktigt byggt kan inte betraktas som ett XML-dokument; XML-processorn (parser) ska inte hantera den på vanligt sätt och måste klassificera situationen som ett dödligt fel.
- Giltig (Giltig). Det faktiska dokumentet motsvarar dessutom några semantiska regler. Detta är en strängare ytterligare verifiering av korrektheten av ett dokument för överensstämmelse med förutbestämda, men redan externa regler, för att minimera antalet fel, till exempel strukturen och sammansättningen av detta, specifika dokument eller dokumentfamilj. Dessa regler kan utvecklas av både användaren själv och tredjepartsutvecklare, till exempel, ordböcker eller datautbytesstandarder. Vanligtvis lagras sådana regler i särskilda filer - System där de flesta i detalj Dokumentets struktur beskrivs, alla tillåtna namn på elementen, attribut och mycket mer. Och om dokumentet till exempel innehåller ett elementnamn som inte är definierat i förskott i system, anses XML-dokumentet ogiltig; Kontrollen XML-processorn (validator) vid kontroll av överensstämmelse med reglerna och systemen är skyldig (genom användarval) att rapportera ett fel.
Dessa två begrepp har inte en ganska väletablerad standardiserad översättning till ryska, särskilt konceptet giltig.som också kan översättas som lösning, sann, pålitlig, lämplig, eller ens testad för överensstämmelse med reglerna, standarderna, lagar. Vissa programmerare används i vardagen i den etablerade spåraren " Giltig».
XML-syntax
I det här avsnittet diskuteras korrekt konstruktion XML-dokument, det vill säga deras syntax.
XML är en hierarkisk struktur avsedd att lagra eventuella data, en visuell struktur kan representeras som ett träd. Det viktigaste obligatoriska syntaktiska kravet är att dokumentet bara har en rotelement (rotelement) (alternativt kallat element i dokumentet). Det betyder att text eller annan data i hela dokumentet måste vara beläget mellan den enda Den ursprungliga rotmärkningen och den slutliga taggen som motsvarar den.
Följande det enklaste exemplet - Korrekt byggt dokument XML:
Kommentar Kan placeras överallt träd. XML kommentarer är inrymda i paret av taggar
. Två tecken på bindestreck (-) kan inte tillämpas i någon del i kommentaren.
Nedan är ett exempel på en enkel kulinarisk receptmärkt med XML:
Strukturera
Resten av detta XML-dokument består av kapslade element, varav några har attribut och innehåll. Element Det består vanligtvis av att öppna och stänga taggar som ramar text och andra element. Öppning tagg Består av ett elementnamn i vinkelfästen, till exempel "
I exemplet på ingredienselementet finns det två attribut: "mängd", som har "3" och "enhet", som har ett "glas" -värde. Från synvinkel av XML Markup gör ovanstående attribut ingen mening, men är bara en uppsättning tecken.
Förutom text kan elementet innehålla andra element:
I det här fallet Elementet "Instruktioner" innehåller tre "steg" -element. XML tillåter inte överlappande element. Till exempel är fragmentet nedan felaktigt, eftersom elementen "em" och "starka" överlappar varandra.
Vanligt accenterad dedikerad och accentuerad tillägnad
Varje XML-dokument måste innehålla exakt en rotelement (rotelement eller dokumentelement.), Så det följande fragmentet kan inte betraktas som ett korrekt XML-dokument.
Att ange ett objekt utan ett innehåll som heter tomt element, nödvändig Applicera en speciell form av en post bestående av en tagg där ett snedstreck placeras efter elementets namn. Om elementet inte deklareras tomt i DTD, men i dokumentet har det inte innehåll för honom tillåten Applicera en sådan post. Till exempel:
XML definierar två metoder för inspelning av specialtecken: Hänvisning till kärnan och länken med symbolnummer. Väsen (Entitet) I XML, heter Data, vanligtvis text, i synnerhet, speciell svällning. Länk till essens Entity referenser) indikeras på den plats där kärnan ska vara och består av Ampersand ("&"), namnet på kärnan och punkten med ett komma (";"). I XML finns det flera fördefinierade enheter, till exempel "LT" (du kan skriva det till det "< ») для левой угловой скобки и « amp » (ссылка - « & ») для амперсанда, возможно также определять собственные сущности. Помимо записи с помощью сущностей отдельных символов, их можно использовать для записи часто встречающихся текстовых блоков. Ниже приведён пример использования предопределённой сущности для избежания использования знака амперсанда в названии:
En komplett lista över fördefinierade enheter består av & "&"),< («<»), > ("\u003e"), "(" ") Och" ("") - de två sista är användbara för registrering av separatorer inom attributvärden. Du kan bestämma dina enheter i DTD-dokument.
Ibland är det nödvändigt att bestämma inspeterande gapVilket används ofta i HTML och indikeras som i XML, det finns ingen sådan förutbestämd enhet, den är skriven, och användningen orsakar ett fel. Frånvaron av denna mycket vanliga essens i en mängd olika programmerare är ofta överraskande och det skapar vissa svårigheter när de migrerar sina HTML-utveckling i XML.
Länk med symbolnummer (Numerisk teckenreferens) ser ut som en referens till en essens, men i stället för essensens namn anges symbolen # och numret (i en decimal eller hexadecimal post), vilket är teckennummeret i Unicode-kodtabellen. Dessa är vanligtvis symboler som inte kan kodas direkt, till exempel, bokstaven i det arabiska alfabetet i ASCII-kodat dokument. Ampersand kan representeras enligt följande:
Det finns fortfarande många regler om sammanställningen av det korrekta XML-dokumentet, men syftet med detta sammanfattning Det var bara att visa de fundament som var nödvändiga för att förstå strukturen i XML-dokumentet.
Historia
XML: s födelsedag kan betraktas som 1996, i slutet av vilken en grov version av språkspecifikationen uppstod, eller när denna specifikation godkändes. Allt började med utseendet på SGML-språk 1986.
SGML (standard generaliserat markup språk - ett standard generaliserat markup språk) förklarade sig som ett flexibelt, omfattande och omfattande meta språk för att skapa märkningsspråk. Trots det faktum att begreppet hypertext uppträdde 1965 (och de grundläggande principerna formulerades 1945), har SGML inte en hypertextmodell. Att skapa SGML kan med förtroende för att kalla ett försök att argumentera enormt, eftersom det kombinerar sådana möjligheter som är extremt sällan används tillsammans. Detta är den främsta nackdelen - komplexitet och som ett resultat begränsar den höga kostnaden för detta språk endast sin användning av stora företag som har råd att köpa rätt programvara Och hyra högt betalda specialister. Dessutom uppstår små företag sällan så svåra uppgifter för att locka sgml för att lösa dem.
Den mest allmänt sgml används för att skapa andra markupspråk, det var med hjälp av ett språk i Markup of Hypertext-dokument - HTML, vars specifikation godkändes 1992. Hans utseende var förknippat med behovet av att organisera ett snabbt ökande utbud av dokument på Internet. Den snabba ökningen av antalet internetanslutningar och följaktligen ledde webbservrarna till ett sådant behov av kodning elektroniska dokumentMed vilken SGML inte kunde klara av den stora svårigheten att mastera. Utseendet på HTML är ett mycket enkelt markupspråk - snabbt löst detta problem: lätthet i studien och rikedom av pappersarbete gjorde det mest populära för internetanvändare. Men som kvantitet och förändringar i kvaliteten på dokument i nätverket växte kraven i nätverket och enkelheten hos HTML förvandlades till sin huvudsakliga nackdel. Det begränsade antalet taggar och fullständig likgiltighet till dokumentets struktur ledde till att utvecklarna i ansiktet av W3C-konsortiet skulle skapa ett sådant markeringsspråk, vilket inte skulle vara så komplicerat som SGML, och inte så primitivt som HTML. Som ett resultat, som kombinerar enkelheten hos HTML, SGML Markup Logic och tillfredsställande Internetkraven, uppträdde XML-språket.
Fördelar och nackdelar
Värdighet
nackdel
- Tvetydigheten av modellering.
- XML innehåller inte inbyggd datatypstöd. Det finns ingen strikt typing i det, det vill säga begreppen "heltal", "strängar", "datum", "booleska värderingar" och så vidare.
- Hierarkisk datamodell som erbjuds av XML är begränsad jämfört med relationell modell och objektorienterade grafer och nätverksmodell data.
XML-kartläggning i World Wide Web
De vanligaste sätten att konvertera ett XML-dokument till användarens visad vy är:
- Användningen av CSS-stilar;
- Tillämpning av XSLT-omvandling;
- Skriva på något programmeringsspråk i XML-dokumenthanteraren.
Utan att använda CSS eller XSL visas XML-dokumentet som en enkel text i de flesta webbläsare. Vissa webbläsare, som Internet Explorer, Mozilla och Mozilla Firefox visar strukturen av ett träd i form av ett träd, så att du kan vända och distribuera noder med hjälp av musknappen.
Tillämpning av CSS-stilar
Processen liknar användningen av CSS till ett HTML-dokument som ska visas.
För att tillämpa CSS när du visar i webbläsaren, XML-dokument Måste innehålla en speciell länk till stilarket. Till exempel:
Det skiljer sig från HTML-tillvägagångssättet, där elementet används. .
Användningen av XSLT-transformation
XSL är en teknik som beskriver hur man formaterar eller konverterar XML-dokumentdata. Dokumentet omvandlas till ett format som är lämpligt för visning i webbläsaren. Browser är den vanligaste användningen av XSL, men du får inte glömma att du använder XSL du kan omvandla XML till något format, till exempel
För att automatiskt konvertera innehållet i XML-filer till läsbar vy / format (HTML, RTF, PDF, TXT, VRML, SVG, Java, etc.) - XSLT ska användas istället för att försöka tillämpa CSS.
CSS nackdelar:
1. CSS kan inte ändra beställningen av elementen i XML-dokumentet. Om du vill sortera några element eller filtrera dem till någon egendom, sedan CSS du definitivt inte en assistent.
2. CSS utför inte beräkningar. Om du vill beräkna och mata ut ett värde (till exempel, summera upp numeriska värden Alla objekt i XML-dokumentet), CSS passar dig inte.
3. CSS kan inte slå samman dokument. Om du vill kombinera ett par dussin XML-dokument med inköpsorder och skriv ut en sammanfattning av alla beställda varor, kommer CSS inte att hjälpa dig igen.
Lite exempel på att använda XSL
Det finns några XML-plugininställningsfil:
Plugin styr inställningarna för AutoCAD-ritningarna. Nedan är ett bord som listar de verifierade positionerna.
Kontrollera namnet på lagret
Sann.
Kontrollera namnet på lagret för att överensstämma med reglerna för byggnamn
Kontrollera färglagret
Sann.
Inspektionen till skiktet är tilldelat färger från paletten "Index Color"
Kontrollera typlinjen
Sann.
Kontrollera att lagren endast tilldelade typer av linjer från en viss uppsättning
Kontrollera tjockleken på linjerna
Sann.
Kontrollera att skikten endast är ordinerad tjocklek av linjer från en viss uppsättning
Kontrollera tillgänglighet
Sann.
Varje lager måste ha en anteckning, dechiffrera sitt syfte
Fast uppsättning lager
falsk
Oavsett om det är nödvändigt att förbjuda användare att skapa ytterligare lager, enligt de regler som fastställs i standarden
Plugin måste läsa inställningarna från det och arbeta enligt dem. Samtidigt bör viss dokumentation vara närvarande som användarna skulle läsa och förstå. Dessutom måste materialet som anges i dokumentationen motsvara de inställningar som för närvarande är installerade. För att inte hålla i huvudet, efter att du har matat inställningarna, måste du klättra och redigera dokumentationen, du kan föreställa dig allt detta i form av en XML-fil. Pluggen läser inställningarna från det, och användaren - Öppna den i webbläsaren och ... Se den i den "mänskliga" formen ... För att göra detta, skapa en stylesheet.xsl-fil med sådant innehåll:
Inställningar Plugin
Parametervärde
Nu, om användaren i webbläsaren öppnar vår XML-fil, kommer han inte att trasslad (från hans synvinkel), obekväma XML-text, och det här är:
I detta exempel Jag visade inte prover, sortering, filtrering, olika typer av drift och beräkningar (de behövdes inte här), men om det behövs kan allt detta göras med XSLT.
5 svar
Vad ditt hjärta berättar är rätt. Även om du kan använda CSS för XML, har XML själv inte semantik. CSS är avsedd för Internet, för HTML och att tillhandahålla semantiska data (bra) arter.
XML är vanligare än det. XSLT uppfanns för att omvandla ett enda dataformat till ett annat (XSLT 1.0 endast XML, XSLT 2.0 - vilket Unicode-dataformat), det vill säga XML i HTML eller XML i XSL-FO eller annat xML-format eller text. XSL-FO uppfanns för att rymma XML på papper eller skärm och mycket mer detaljerad än CSS.
Vissa fördelar och nackdelar i CSS + XML
Mestadels minuses, speciellt. Mot bakgrund av att använda XML i webbläsaren. Hoppa över det allmänna rådet nedan om du inte vill ha all min chatter; -)
CSS minus 1: Nej CSS + XML för Internet
Mot: Detta är mycket beroende av sammanhanget, men om du vill använda XML för att visa på Internet, tänk igen: Använd inte XML och konvertera den till HTML. Använd sedan CSS + HTML för att visa dina data. Om du använder XML på Internet, nej sökmotor eller sökare, förstår inte skillnaden mellan och
.
Detta är i sig en tillräcklig grund för att använda XSLT för att konvertera till HTML + CSS och XML-undantag.
CSS CONS 2: CSS betyder mycket mer arbete
Andra extremt en viktig anledningsom du kan använda: XML + CSS betyder definitionen av varje element i CSS. Att använda HTML + CSS innebär att anpassade agenter redan känner till standardlayoutegenskaperna för alla objekt. Med XML. + XSLT betyder att du brukar skapa HTML + CSS. Du måste göra det på serverns sida, eftersom kunden XSLT inte är mycket tillförlitlig och kompatibel med cross webbläsaren.
CSS CONS 3: Tillgänglighet
(Tyvärr, jag kan inte hitta ett pro). Om XML inte har semantik (SVG, som nämns av en annan användare), är det ingen mening att använda CSS för layout. Om layouten förmodligen förstås av användaren, fungerar inte XML + CSS. Att läsa texten i tal har inte begreppet vad man ska göra, är noggrannheten i WAI (tillgänglighet) att vara omöjlig, etc.
CSS CONS 4: Underhållbarhet, tydligare, skript, problem
Att använda XML gör det svårt att utföra några klientsidoscenarier (ja, DOM är tillgängligt, men hur säger du webbläsaren, vad är script -tag? Men kanske kommer han att reagera på