NO329240B1 - System og fremgangsmate for forklarende definering og bruk av undergrupper innenfor dokumentkoding - Google Patents
System og fremgangsmate for forklarende definering og bruk av undergrupper innenfor dokumentkoding Download PDFInfo
- Publication number
- NO329240B1 NO329240B1 NO20032232A NO20032232A NO329240B1 NO 329240 B1 NO329240 B1 NO 329240B1 NO 20032232 A NO20032232 A NO 20032232A NO 20032232 A NO20032232 A NO 20032232A NO 329240 B1 NO329240 B1 NO 329240B1
- Authority
- NO
- Norway
- Prior art keywords
- subclass
- assembly
- computer
- definition
- generating
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims description 80
- 230000000576 supplementary effect Effects 0.000 claims 9
- 238000012545 processing Methods 0.000 description 33
- 230000008569 process Effects 0.000 description 24
- 230000000712 assembly Effects 0.000 description 19
- 238000000429 assembly Methods 0.000 description 19
- 230000006870 function Effects 0.000 description 15
- 230000007246 mechanism Effects 0.000 description 15
- 238000010586 diagram Methods 0.000 description 8
- 230000008901 benefit Effects 0.000 description 6
- 238000004891 communication Methods 0.000 description 6
- 230000000153 supplemental effect Effects 0.000 description 4
- 238000004364 calculation method Methods 0.000 description 3
- 238000010276 construction Methods 0.000 description 3
- 238000011161 development Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 238000007726 management method Methods 0.000 description 2
- 238000013507 mapping Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000006399 behavior Effects 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 239000003607 modifier Substances 0.000 description 1
- 239000013589 supplement Substances 0.000 description 1
- 230000007723 transport mechanism Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/31—Programming languages or programming paradigms
- G06F8/315—Object-oriented languages
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/10—Text processing
- G06F40/12—Use of codes for handling textual entities
- G06F40/14—Tree-structured documents
- G06F40/143—Markup, e.g. Standard Generalized Markup Language [SGML] or Document Type Definition [DTD]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/51—Source to source
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
- G06F9/4488—Object-oriented
- G06F9/4492—Inheritance
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/451—Execution arrangements for user interfaces
- G06F9/453—Help systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/451—Execution arrangements for user interfaces
- G06F9/454—Multi-language systems; Localisation; Internationalisation
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Artificial Intelligence (AREA)
- Health & Medical Sciences (AREA)
- Audiology, Speech & Language Pathology (AREA)
- Computational Linguistics (AREA)
- General Health & Medical Sciences (AREA)
- Human Computer Interaction (AREA)
- Stored Programmes (AREA)
- Devices For Executing Special Programs (AREA)
- Compression, Expansion, Code Conversion, And Decoders (AREA)
- Error Detection And Correction (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
I dag gjør programvareutviklingsverktøy det mulig for programvareutvik-lere å bygge eksekverbare komponenter ved anvendelse av ett eller flere programmeringsspråk, så som C, C++, C# og liknende. Én fordel ved å bygge eksekverbare komponenter er at komponentene, når de er bygget, kan gjenbrukes av andre programmer. En annen fordel ved å bygge eksekverbare komponenter er at nye komponenter på en enkel måte kan avledes fra eksisterende komponenter.
Generelt blir komponenter utvidet ved å implementere en underklasse, hvilket betyr å avlede en ny klasse fra en eksisterende klasse. Disse klassene og underklassene blir skrevet ved anvendelse av ett av programmeringsspråk-ene. Koden som skrives blir vanligvis betegnet kildekode. I tradisjonelle kjøre-miljøer kompilerer programvareutviklingsverktøyene kildekoden til objektkode og linker deretter flere objektkoder sammen for å skape en eksekverbar fil. Ett av problemene med disse tradisjonelle kjøremiljøene er imidlertid det at hvert programmeringsspråk og hver versjon av programmeringsspråket krever et forskjellig kjøremiljø.
For å overkomme dette problemet har det blitt utviklet en ny type kjøre-miljø som effektivt eliminerer mange av problemene med grensesnittet mellom
språkene og språkversjonene i de tradisjonelle kjøremiljøene. I denne nye typen kjøremiljø kompilerer utviklingsverktøy kildekoden til et mellomspråk. Ved kjøre-tid kompilerer kjøremiljøet mellomspråket til intern binær, eksekverbar kode. Det nye kjøremiljøet utfører således "linke"-prosessen ved kjøretid. For å utføre
denne "linke-type" prosessen, leser kjøremiljøet informasjon (f.eks. metadata) og aksesserer IL-assembleringer for de komponentene som er assosiert med det programmet som kjøres. Metadataene omfatter beskrivelser av typer, ver-sjoner, ressurser og liknende. IL-assembleringene kan være ett enkelt dyna-misk linket bibliotek (DLL) eller flere DLL-biblioteker og ressurser.
I både det tradisjonelle og den nye typen kjøremiljø blir kildekode skrevet ved anvendelse av et programmeringsspråk. Hvert programmeringsspråk har sin egen unike syntaks og sitt eget sett av API (application programming inter-face)-funksjoner som er spesifikke for kjøremiljøet. For at en programmerer skal kunne skrive kildekode, må utvikleren først lære seg programmeringsspråkets syntaks og de API-funksjonene som er assosiert med kjøremiljøet. Det å lære seg syntaksen og API-funksjonene er veldig tidkrevende og utfordrende. I tillegg, dersom en utvikler ønsker å programmere i flere programmeringsspråk og/eller forskjellige kjøremiljøer, må utvikleren huske likhetene og de subtile for-skjellene mellom hvert av programmeringsspråkenes syntaks og API-funksjonene for de forskjellige kjøremiljøene.
US 2003/0037311 A1 beskriver en fremgangsmåte og apparat som anvender datamaskin script-språk i multimedia anvendelsesplattformer. Det datamaskinimplementerte systemet og fremgangsmåten utfører en mengde forskjellige oppgaver relatert til skapelsen, forvaltningen og presentasjonen av multimediainnhold.
Gitt fordelene ved å anvende komponenter, er det behov for en bedre mekanisme for å bygge, utvide og anvende komponenter.
I et første aspekt tilveiebringer oppfinnelsen et datamaskinlesbart medium innkodet med en datamaskinlesbar datastruktur, der datastrukturen omfatter: et skjema for forklarende definering av en underklasse-definisjon i et formatkodet dokument, idet skjemaet kan bli kompilert til en eksekverbar assemblering som instansierer et objekt som er assosiert med en underklasse som er definert innenfor underklasse-definisjonen ved eksekvering av assembleringen, hvor den eksekverbare assemblering er uavhengig av et programmeringsspråk som opprinnelig er benyttet for å skape assembleringen slik at den eksekverbare sammenstillingen er kompilert uten hensyn til programmeringsspråket.
I et andre aspekt tilveiebringer oppfinnelsen et datamaskinlesbart medium som inneholder instruksjoner for å generere en eksekverbar assemblering for en underklasse, der instruksjonene omfatter det å: identifisere en underklasse-definisjon i et formatkodet dokument, idet underklasse-definisjonen definerer en underklasse; og
generere en assemblering basert på underklasse-definisjonen, idet assembleringen kan bli eksekvert for å opprette en instans av et objekt assosiert med underklassen, hvor den genererte assemblering er uavhengig av et programmeringsspråk som opprinnelig er benyttet for å skape assembleringen
slik at den genererte sammenstillingen er eksekvert uten hensyn til programmeringsspråket.
I et tredje aspekt tilveiebringer oppfinnelsen en datamaskin-implementert fremgangsmåte for å generere en eksekverbar assemblering, idet fremgangsmåten omfatter det å: identifisere en underklasse-definisjon i et formatkodet dokument, der underklasse-definisjonen definerer en underklasse; og
generere en assemblering basert på underklasse-definisjonen, idet assembleringen kan eksekveres for å opprette en instans av et objekt assosiert med underklassen, hvor den genererte assemblering er uavhengig av et programmeringsspråk som opprinnelig er benyttet for å skape assembleringen slik at den genererte sammenstillingen er eksekvert uten hensyn til programmeringsspråket.
I et fjerde aspekt tilveiebringer oppfinnelsen et datamaskinlesbart medium som omfatter instruksjoner for å skape en eksekverbar assemblering for en underklasse, idet instruksjonene omfatter fremgangsmåten angitt over.
I et femte aspekt tilveiebringer oppfinnelsen et datasystem for å generere en assemblering fra en underklasse-definisjon med et formatkodet dokument, der datasystemet omfatter:
en prosessor; og
et minne, der minnet er allokert forflere datamaskin-eksekverbare instruksjoner som blir lastet inn i minnet, hvor prosessoren eksekverer instruksjonene for å: identifisere en underklasse-definisjon i et formatkodet dokument, idet underklasse-definisjonen definerer en underklasse; og
generere en assemblering basert på underklasse-definisjonen, idet assembleringen kan bli eksekvert for å opprette en instans av et objekt assosiert med underklassen, hvor den genererte assemblering er uavhengig av et programmeringsspråk som opprinnelig er benyttet for å skape assembleringen slik at den genererte sammenstillingen er eksekvert uten hensyn til programmeringsspråket.
I et sjette aspekt tilveiebringer oppfinnelsen en datamaskin-implementert fremgangsmåte for å generere en eksekverbar assemblering, idet fremgangsmåten omfatter: et middel for å identifisere en underklasse-definisjon i et formatkodet dokument, der underklasse-definisjonen definerer en underklasse; og
et middel for å generere en assemblering basert på underklasse-definisjonen, der assembleringen kan eksekveres for å opprette en instans av et objekt assosiert med underklassen, hvor den genererte assemblering er uavhengig av et programmeringsspråk som opprinnelig er benyttet for å skape assembleringen slik at den genererte sammenstillingen er eksekvert uten hensyn til programmeringsspråket.
Foreliggende oppfinnelse er rettet mot et system og en fremgangsmåte for forklarende definering, utvidelse og bruk av underklasser innenfor dokumentkode. Oppfinnelsen tilveiebringer en mekanisme for utviklere til å bygge, utvide og anvende komponenter ved anvendelse av et formatteringsspråk. Disse komponentene omfatter komponenter som kan gjenbrukes, API-funksjo-ner, dokument-brukergrensesnitt og liknende. Mekanismen krever ikke at en utvikler kan et programmeringsspråk. I stedet gjør mekanismen det mulig for brukeren å anvende et kjent formatteringsspråk, så som XML (extensible markup language), for å bygge komponenter. Ettersom XML er mye enklere å lære, og er i ferd med å bli mer kjent innenfor de generelle dataprogrammeringsmiljøene, tilbyr foreliggende oppfinnelse mange fordeler fremfor det å anvende tradisjonelle programmeringsspråk. Én fordel er at komponenter kan bli definert i et formatkodet dokument, sammen med annen formatkodet tekst, for å skape et veldig sofistikert elektronisk dokument. En annen fordel er at utviklere ikke trenger å kunne eller forstå noe programmeringsspråk for å generere en eksekverbar komponent.
Systemet, fremgangsmåten og datastrukturen ifølge foreliggende oppfinnelse gjør det mulig å generere en eksekverbar assemblering assosiert med en underklasse fra en underklasse-definisjon som er skrevet i et formatkodet dokument. Ifølge oppfinnelsen skrives underklasse-definisjonen basert på et skjema. Skjemaet kan være XML-basert. Skjemaet omfatter en underklasse-etikett for å definere et navn for underklassen. Navnet blir assosiert med en type for et objekt som blir instansiert når den eksekverbare assembleringen blir eksekvert. Skjemaet omfatter videre ett eller flere hint, for eksempel for å spesifisere et programmeringsspråk for å kompilere underklasse-definisjonen, for å spesifisere en baseklasse fra hvilken underklassen skal avledes, for å spesifisere handlinger å utføre når objektet blir instansiert, for å opprette en hendelse-definisjon og en assosiert hendelsehåndterer for underklassen og for å spesifisere en egenskap som blir en medlemsvariabel i objektet når objektet instansieres. Figur 1 illustrerer et eksempel på beregningsanordning som kan anvendes i forklarende implementasjoner av foreliggende oppfinnelse. Figur 2 er et funksjonelt blokkdiagram som illustrerer generelt komponenter for å implementere én utførelsesform av foreliggende oppfinnelse. Figur 3 er et funksjonelt blokkdiagram som illustrerer generelt et kjøre-miljø for å implementere én utførelsesform av foreliggende oppfinnelse. Figurene 4-6 illustrerer en serie av hoveddeler av formatkodede dokumenter som illustrerer et eksempel på syntaks for forklarende definering av underklasser ifølge én utførelsesform av foreliggende oppfinnelse. Figur 7 illustrerer hoveddeler av et formatkodet dokument som illustrerer et eksempel på syntaks for å anvende en eksekverbar komponent fra inne i et formatkodet dokument. Figur 8 er et logisk flytdiagram som illustrerer generelt en prosess for å kompilere deklarativt definerte underklasser ifølge én utførelsesform av foreliggende oppfinnelse. Figur 9 er et logisk flytdiagram som illustrerer generelt en kjøretidprosess for anvendelse av underklasser som er deklarert i et formatkodet dokument ifølge én utførelsesform av foreliggende oppfinnelse. Figur 10 er et kildekodeeksempel som lister motsvarende kildekode som er generert av formatteringsspråk-kompilatoren vist i figur 2 basert på formatkodede dokumenter illustrert i figurene 4-6.
Foreliggende oppfinnelse er rettet mot et system og en fremgangsmåte for deklarativ definering, utvidelse og bruk av underklasser i et formatkodet dokument. Oppfinnelsen tilveiebringer en mekanisme for utviklere til å bygge, utvide og bruke komponenter ved anvendelse av et formatteringsspråk. Mekanismen krever ikke at en utvikler kan et programmeringsspråk. I stedet gjør mekanismen det mulig for brukeren å anvende et kjent formatteringsspråk, så som XML (extensible markup language), for å bygge komponenter.
Illustrativt beregningsmiliø
Figur 1 illustrerer et eksempel på beregningsanordning som kan anvendes i forklarende implementasjoner av foreliggende oppfinnelse. Med henvisning til figur 1, i en helt grunnleggende konstruksjon, omfatter beregningsanordningen 100 typisk minst én prosesseringsenhet 102 og et systemminne 104. Avhengig av den eksakte konstruksjonen og typen av beregningsanordning 100, kan systemminnet være volatilt (så som RAM), ikke-volatilt (så som ROM, flash-minne, etc.) eller en kombinasjon av de to. Systemminnet 104 omfatter typisk et operativsystem 105, én eller flere programmoduler 106, og kan omfatte programdata 107. Eksempler på programmoduler 106 omfatter en browser-app-likasjon, en finansadministreringsapplikasjon, en tekstbehandler og liknende. Denne grunnleggende konstruksjonen er illustrert i figur 1 av komponentene innenfor den stiplede boksen 108.
Beregningsanordningen 100 kan omfatte ytterligere mekanismer eller funksjonalitet. For eksempel kan beregningsanordningen 100 også omfatte ytterligere datalagringsanordninger (flyttbare og/eller ikke-flyttbare) så som, for eksempel, magnetdisker, optiske disker eller bånd. Slike ytterligere lagre er illustrert i figur 1 av et flyttbart lager 109 og et ikke-flyttbart lager 110. Datamaskin-lagringsmedier kan omfatte volatile og ikke-volatile, flyttbare og ikke-flyttbare medier som er implementert med en hvilken som helst fremgangsmåte eller teknologi for lagring av informasjon, så som datamaskinlesbare instruksjoner, datastrukturer, programmoduler eller andre data. Systemminnet 104, det flyttbare lageret 109 og det ikke-flyttbare lageret 110 er alle eksempler på datamaskin-lagringsmedier. Datamaskin-lagringsmedier omfatter, men er ikke begrenset til, RAM, ROM, EEPROM, flash-minne eller annen minneteknologi, CD-ROM, DVD eller annen optisk lagring, magnetkasetter, magnetbånd, magnetdisklagre eller andre magnetiske lagringsanordninger, eller et hvilket som helst annet medium som kan anvendes for å lagre den ønskede informasjonen og som kan aksesseres av beregningsanordningen 100. Ethvert slikt datamaskin-lagrings-medium kan være en del av anordningen 100. Beregningsanordningen 100 kan også ha én eller flere inndataanordninger 112 så som tastatur, mus, penn, stemmeinnmatingsanordning, berøring-innmatingsanordning, etc. Én eller flere utdataanordninger 114, så som en monitor, høyttalere, en skriver etc. kan også være inkludert. Disse anordningene er velkjente for fagmannen, og trenger ikke diskuteres utførlig her.
Beregningsanordningen 100 kan også omfatte kommunikasjonsforbindel-ser 116 som gjør det mulig for anordningen 100 å kommunisere med andre be-regningsanordninger 118, for eksempel over et nettverk. Kommunikasjonsfor-bindelsene 116 er ett eksempel på kommunikasjonsmedium. Kommunikasjonsmedier kan typisk være innlemmet i datamaskinlesbare instruksjoner, datastrukturer, programmoduler eller andre data i et modulert datasignal, så som er bær-erbølge eller en annen transportmekanisme, og omfatter ethvert informasjons-leveringsmedium. Betegnelsen "modulert datasignal" betyr et signal som får én eller flere av sine egenskaper satt eller endret på en slik måte at det innkodes informasjon i signalet. Som et eksempel, og uten begrensning, omfatter kommunikasjonsmedier kabelbaserte medier så som kablede nettverk eller en direkte ledningsforbindelse, samt trådløse medier så som akustiske, RF-baserte, infrarøde eller andre trådløse medier. Betegnelsen datamaskinlesbart medium, som anvendt her, omfatter både lagringsmedier og kommunikasjonsmedier.
Forklarende implementasjon
Figur 2 er et funksjonelt blokkdiagram som illustrerer generelt et utvik-lingssystem for å implementere én utførelsesform av foreliggende oppfinnelse. Systemet omfatter en formateringsspråk-kompilator 202 og en parser 204. Formateringsspråk-kompilatoren 202 og parseren 204 er programvaremoduler (dvs. programmoduler 106 vist i figur 1) som kan befinne seg i en beregningsanordning, så som beregningsanordningen 100 vist i figur 1. Formateringsspråk-kompilatoren 202 tar inn et formatkodet dokument 206.1 én utførelses-form er det formatkodede dokumentet 206 et XML-basert dokument. Kort opp-summert omfatter det formatkodede dokumentet 206, som er illustrert i figurene 4-6 og beskrevet i detalj nedenfor, etiketter (ikke vist) som angir deler av en underklasse-definisjon. Som vil bli beskrevet i detalj senere, angir etikettene at det skal skapes en underklasse og assosierte elementer. Når den møter på disse etikettene, begynner formateringsspråk-kompilatoren 202 å kommunisere med parseren 204 for å bygge underklassen.
I én utførelsesform kan den funksjonaliteten som tilveiebringes av parseren 204 være tilveiebrakt inne i formateringsspråk-kompilatoren 202.1 en annen utførelsesform kan den funksjonaliteten som tilveiebringes av parseren 204 være tilveiebrakt ved avledning av en parser-klasse fra en eksisterende parser-klasse i formateringsspråk-kompilatoren 202. Den avledede parser-klassen kan omfatte funksjon-redefinisjoner for hvert av underklassesymbolene (dvs. etikettene) som er definert ifølge foreliggende oppfinnelse. Kort beskrevet kan funksjon-redefinisjonene, som illustrert i figur 10 og beskrevet i detalj nedenfor, være en del av en serie av tilbakekallsfunksjoner som signaliserer en be-gynnelse av og en slutt på definisjonene av de elementene som er assosiert med underklassen.
Parseren 204 er innrettet for å analysere underklasse-definisjoner innenfor det formatkodede dokumentet 206. Kort beskrevet kompilerer formateringsspråk-kompilatoren 202 innhold inne i det formatkodede dokumentet 206.1 én utførelsesform konverterer formateringsspråk-kompilatoren 202 innholdet til en symbolbasert binærstrøm som blir lagret i en symbolbasert binærfil 208. Den symbolbaserte binærfilen 208 kan være på ett av flere formater som er kjente for fagmannen. Den symbolbaserte binærfilen 208 representerer et tre av komponenter som er spesifisert i det formatkodede dokumentet 206. Formateringsspråk-kompilatoren 202 kan imidlertid være uten mulighet for å konvertere noe av innholdet direkte, og dette innholdet kan bli sendt til parseren 206. Underklasse-definisjonene som er definert i det formatkodede dokumentet 206 i henhold til foreliggende oppfinnelse er et eksempel på slikt innhold. Parseren 204 identifiserer egenskaper, hendelser og liknende i underklasse-definisjonene og videresender relevant informasjon om disse elementene til formateringsspråk-kompilatoren 202.
Når den mottar den relevante informasjonen, legger formateringsspråk-kompilatoren 202 til symboler i det formatkodede dokumentet som er assosiert med underklasse-definisjonen. Formateringsspråk-kompilatoren 202 kan også generere representativ kildekode 212 fra hvilken det blir opprettet IL-assembleringer 210. IL-assembleringene 210 omfatter datamaskininstruksjoner for underklasser (f.eks. komponenter) som er definert i det formatkodede dokumentet 206. Tidligere ble disse IL-assembleringene generert ved anvendelse av et pro-gramvareutviklingsverktøy som kompilerte og linket kildekode skrevet i et programmeringsspråk. Fagmannen vil også forstå at, i en annen utførelsesform, formateringsspråk-kompilatoren 202 kan generere IL-assembleringene 210 uten å generere den symbolbaserte binærfilen 208. IL-assembleringene 210 som blir opprettet av formateringsspråk-kompilatoren 202 kan gjenbrukes av tradisjonelle programvareutviklingsverktøy. I tillegg kan IL-assembleringene 210 gjenbrukes i andre formatkodede dokumenter. Muligheten for å gjenbruke IL-assembleringene 210 i et formatkodet dokument er illustrert i figur 7 og beskrevet i forbindelse med denne. Foreliggende oppfinnelse gir således komponentutviklere mulighet for på en enkel måte å bygge og utvide komponenter ved anvendelse av et formatteringsspråk. Når nye komponenter har blitt bygget i henhold til foreliggende oppfinnelse, ser de nye komponentene ut som om de er bygget ved anvendelse av et tradisjonelt programmeringsspråk. Utviklere som anvender mekanismen og fremgangsmåten ifølge foreliggende oppfinnelse kan således bygge komponenter uten å lære seg syntaksen og nyansene til ett eller flere programmeringsspråk.
Figur 3 er et funksjonelt blokkdiagram som illustrerer generelt et kjøre-miljø for å implementere én utførelsesform av foreliggende oppfinnelse. Kjøre-miljøet omfatter en kjøremotor 302, en symbolbasert binærleser 304, og en symbolbasert binærlaster 306. Når kjøremotoren 302 mottar en forespørsel om å laste inn en gitt ressurs (f.eks. det formatkodede dokumentet 206 vist i figur 2), aksesserer kjøremotoren 302 en sideavbildningstabell 308. Sideavbild-ningstabellen 308 identifiserer hvorvidt det formatkodede dokumentet 206 har en kompilert versjon (f.eks. en symbolbasert binærfil 208). Dersom det eksisterer en kompilert versjon, kommuniserer kjøremotoren 302 med den symbolbaserte binærlasteren 306 for å laste inn den symbolbaserte binærfilen 208.1 én ut-førelsesform identifiserer den symbolbaserte binærfilen 208 IL-assembleringer (f.eks. IL-assembleringen 210) som er assosiert med den symbolbaserte binærfilen 208. Den symbolbaserte binærlasteren 306 laster da de identifiserte IL-assembleringene 210. Når en andel av eller hele den symbolbaserte binærfilen 208 og de assosierte IL-assembleringene 210 har blitt lastet, begynner den symbolbaserte binærleseren 304 å lese den symbolbaserte binærfilen 208 og IL-assembleringene 210 for å generere interne instruksjoner som blir eksekvert av en prosessor (f.eks. prosesseringsenheten 102 vist i figur 1). Den symbolbaserte binærleseren 304 kan aksessere metadata 310 for å bestemme innfor-masjon så som typer, metoder og hendelser. Generelt omfatter metadataene 310 informasjon om metoder, felter, egenskaper og hendelser. Hvert av disse elementene kan ha sine egne metadata som kan leses for ytterligere detaljer. Ved å anvende metadataene 310, tar således den symbolbaserte binærleseren 304 avgjørelser ved kjøretid for programmatisk å bestemme informasjon om elementene i den symbolbaserte binærfilen 208.1 tillegg, som vil bli beskrevet i detalj senere, kan underklasser som originalt er definert i det formatkodede dokumentet 206 bli eksekvert direkte ved anvendelse av IL-assembleringene 210 opprettet i henhold til foreliggende oppfinnelse.
Figurene 4-6 illustrerer en serie av hoveddeler av dokumentkode i det formatkodede dokumentet 206 som illustrerer et eksempel på syntaks for deklarativ definering av underklasser ifølge én utførelsesform av foreliggende oppfinnelse. Figur 10 er en eksempelvis kildekodelisting som illustrerer motsvarende kildekode som formateringsspråk-kompilatoren 202 kan generere basert på dokumentkoden vist i figurene 4-6.1 én utførelsesform kan formateringsspråk-kompilatoren 202 generere en fil som inneholder den representative kildekoden. Dette kan for eksempel skje når en utvikler har satt et debug-flagg. Filen som
inneholder den representative kildekoden gjør det da mulig for utvikleren å identifisere mulige problemer i teksten i det formatkodede dokumentet 206 eller problemer i formateringsspråk-kompilatoren 202.1 en annen utførelsesform trenger ikke den representative koden bli lagret til en fil. I denne utførelsesformen kan
formateringsspråk-kompilatoren 202 generere den symbolbaserte binærfilen 208 og IL-assembleringene 210 med eller uten først å generere den første motsvarende kildekoden.
Som en oppsummering beskriver seriene i figurene 4-6 stegvis forskjellige aspekter for deklarativ definering av en underklasse i dokumentkode ifølge foreliggende oppfinnelse. Figur 4 illustrerer et eksempel på syntaks for å definere en underklasse og et underklasse-hierarki. Figur 5 illustrerer et eksempel på syntaks for å definere identifikatorer, kode samt konstruktorer eller instansi-eringsmetoder for underklassen. Figur 6 illustrerer et eksempel på syntaks for å definere egenskaper og hendelser for underklassen. Hver av disse figurene vil nå bli beskrevet i detalj.
Figur 4 illustrerer et eksempel på syntaks for å definere en underklasse og et underklasse-hierarki. Den viste delen av dokumentkoden 400 (dvs. underklasse-definisjonen) omfatter en baseklasse-etikett 402 (f.eks. "Button"). For den følgende diskusjonen har hver etikett (f.eks. baseklasse-etiketten) en motsvarende slutt-etikett. For enkelhets skyld er ikke slutt-etiketten referert til i den skrevne beskrivelsen, men er illustrert i de assosierte figurene. Dokumentkoden 400 omfatter en navnerom-attributt 404, en definisjon-navneromdeklarasjon 406 og flere kompilatorhint (f.eks. hintene 408 og 410). Navnerom-attributten 404 identifiserer navnerommet (f.eks. "System.Control") og den assembleringen i hvilken baseklassen (for eksempel Button) er lokalisert. Definisjon-navneromde-klarasjonen 406 angir at enhver attributt innenfor dokumentkoden 400 som inneholder prefikset "def:" representerer et hint til kompilatoren vedrørende handlinger kompilatoren skal utføre.
For eksempel angir hintet 408 (i det følgende betegnet språkhintet 408) at kompilatoren skal generere IL-assembleringen 210 ved anvendelse av det språket (f.eks. C#) som er tilordnet språkhintet 408. Språkhintet 408 kan tilord-nes et hvilket som helst blant en rekke mulige programmeringsspråk, så som C, C++ og liknende. Hintet 410 (i det følgende betegnet def:Class-hintet 410) angir for kompilatoren at den skal definere underklassen ved anvendelse et navn 414 (f.eks. MyButton) som er tilordnet def:Class-hintet 410. Hintet def:Class 410 kan også omfatte et underklasse-navnerom 412 som identifiserer det navnerommet (f.eks. "MyControlLib") med hvilket den nye underklassen skal være assosiert. I figur 4 har således en utvikler deklarert en ny underklasse med navn "MyButton" som er avledet fra klassen "Button" som er lokalisert i navnerommet "System.Controls". Den nye underklassen vil bli assosiert med navnerommet "MyControlLib".
I den dokumentkoden 400 som er illustrert i figur 4 er det definert en ele-mentdeklarasjonsetikett 420 (f.eks. "Image"). Fordi et spesifikt navnerom ikke er definert i elementdeklarasjonsetiketten 420, definerer navnerom-attributten 404 også lokaliseringen av det elementet (f.eks. "Image") som er assosiert med elementdeklarasjonsetiketten 420. Elementdeklarasjonsetiketten 420 omfatter et element 421 og en kilde-attributt 422. Kilde-attributten 422 omfatter en egenskap 424 (f.eks. "Source") og en verdi 426 (f.eks. "Happyface.jpg"). Fordi elementdeklarasjonsetiketten 420 befinner seg innenfor underklasse-definisjonen for underklassen definert som "MyButton", vil elementene assosiert med elementdeklarasjonsetiketten 420 bli instansiert når underklassen blir instansiert. I tillegg er elementene som er assosiert med elementdeklarasjonsetiketten 420 inneholdt i en underelement-samling i den nye underklassen. Med andre ord er underklassen moderelementet for elementene som er assosiert med element-deklarasjonsetikettene 420. Fagmannen vil derfor forstå at dokumentkoden 400 gjør det mulig for utviklere å uttrykke hierarki på en måte som gjør at kompilatoren kan generere elementtrær som har røtter fra underklassen som blir definert (f.eks. "MyButton").
Figur 5 illustrerer et eksempel på syntaks for å definere identifikatorer, kode og konstruktorer for underklassen. Den viste delen av dokumentkoden 500 omfatter dokumentkoden 400 beskrevet ovenfor i tillegg til dokumentkode for å definere identifikatorer, kode, og konstruktorer. For oversiktens skyld er ikke de referansenumrene som er illustrert i figur 4 og beskrevet ovenfor vist i figur 5 dersom de ikke er nyttige for å beskrive de nye aspektene. I figur 5 omfatter elementdeklarasjonsetiketten 420 videre attributter, så som id-attributten 520 og hendelse-attributten 526. Id-attributten 520 omfatter en id-egenskap (f.eks. "ID") og en id-verdi 523 (f.eks. "img1"). Id-attributten 520 illustrerer et eksempel på mekanisme for å definere identifikatorer for underklassen ifølge foreliggende oppfinnelse.
Hendelse-attributten 526 omfatter en hendelse-trigger (f.eks. "DataLoaded") og en hendelse-verdi 529 (f.eks. "OnLoaded"). Hendelse-triggeren 527 spesifiserer hvilken hendelse som skal monitoreres og hendelse-verdien 529 spesifiserer den metoden som eksekveres når hendelse-triggeren 527 aktiveres. Hendelse-verdien 529 er assosiert med en metode 530 (f.eks. funksjonen "OnLoad"). Metoden 530 kan skrives ved anvendelse av et programmeringsspråk. Metoden 530 kan referere til instanser av en klasse og underklasser som er definert i dokumentkoden 500. Når metoden 530 blir skrevet ved anvendelse av et programmeringsspråk i et formatkodet dokument, assosieres metoden 530 med et kodehint 540. Kodehintet 540 gjør det mulig for utviklere å legge til kodesnutter i legemet av underklasse-definisjonen. I én utførelses-formetterfølger koden kodehintet 540 og er en kallbar metode eller en hendelsehåndterer. I dokumentkoden 500, for eksempel, tjener funksjonen OnLoaded 530 som hendelsehåndterer for hendelsen DataLoaded som reises av Image-kontrollen. Andre kodesnutter kan også bli lagt til i legemet av underklasse-definisjonen, så som funksjonen Customlnit 550 vist i figur 5.
Dokumentkodden 500 omfatter også et konstruktorhint 542. Konstruktor-hintet 542 gjør det mulig for utvikleren å skrive en supplerende konstruktør som supplerer standard-konstruktoren som blir opprettet for en underklasse. I én ut-førelsesform er den supplerende konstruktøren den siste instruksjonen som eksekveres av den genererte standard-konstruktoren. Den supplerende-konstruktoren kan inneholde kode som påvirker oppførselen til underklassen når den instansieres. Utvikleren kan kalle konstruktøren i underklassen til base klassen fra den supplerende konstruktøren. Den supplerende konstruktøren vist i figur 5 kaller funksjonen Customlnit 550, som er en brukerdefinert, privat metode.
Figur 6 illustrerer et eksempel på syntaks for å definere egenskaper og hendelser for underklassen. Den viste delen av dokumentkoden 600 omfatter dokumentkoden 400 og dokumentkoden 500 beskrevet ovenfor i tillegg til dokumentkode for å definere egenskaper og hendelser. For oversiktens skyld er ikke de referansenumrene som er illustrert i figurene 4-5 og beskrevet ovenfor vist i figur 6 dersom de ikke er nyttige for å beskrive de nye aspektene.
Dokumentkoden 600 et omfatter egenskap-hint 610 som gjør det mulig å definere egenskaper for underklassen. Egenskapen tjener som en medlemsvariabel i underklassen. Egenskap-hintet 610 kan omfatte én eller flere attributter, så som navn-attributt 612, type-attributt 614, standardverdi-attributt 616 og flagg-attributt 618. Navn-attributten 612 spesifiserer et navn for egenskapen. I én utførelsesform er navnene case-sensitive, og kjøremotoren legger ingen be-grensninger på de tegn som kan anvendes i navnet. Navnet må være unikt for den eieren som registrerer det. Type-attributten 614 spesifiserer en type for verdien til egenskapen. Typen omfatter intrinsic, user-defined, struct, dass, inter-face, enum og liknende Standardverdi-attributten 616 spesifiserer en verdi som blir tilordnet når egenskapen blir instansiert. Flagg-attributten 618 spesifiserer typen metoder som opprettes av wrapperen når egenskapen blir instansiert. Flaggene kan styre karakteristikkene ved egenskapen, så som ReadOnly, Inheritable to child elements, Private og liknende.
Dokumentkoden 600 omfatter også et hendelse-hint 620. Hendelse-hintet 620 gjør det mulig å definere hendelser for underklassen. Hendelse-hintet 620 kan omfatte attributter, så om navn-attributt 622, route-attributt 624, flagg-attributt 626 og liknende. Navn-attributten 622 spesifiserer den strengen som refererer til denne hendelsen. Når en xml-fil anvender underklassen, anvender xml-filen denne strengen for å binde den korrekte applikasjonsutvikler-definerte koden. Route-attributten 624 spesifiserer den metoden som bestemmer hvilke elementer i treet hendelsen skal trigges for. Flagg-attributten 626 spesifiserer andre karakteristikker som er assosiert med hendelsen. For eksempel, for dokumentkoden 600, vil formatteringsspråk-kompilatoren generere kode for å akti-vere en hendelse kalt DblClick og inkludere informasjon assosiert med hendelsen, så som den støttede rutingen, flagg og liknende. Fagmannen vil forstå at navnene og verdiene assosiert med attributtene kan modifiseres innenfor rammen til foreliggende oppfinnelse.
Dokumentkoden 600 omfatter også en hendelsehåndterer-deklarasjon 630. Hendelsehåndterer-deklarasjonen 630 kan ha assosierte hendelsehåndterer-modifikatorer 632, så som public/private, delegate, returtype og liknende. I figur 6 deklarerer hendelsehåndterer-deklarasjonen 630 en hendelsehåndterer (dvs. metode) (f.eks. "DblClickEventHandler") som blir kalt når den assosierte hendelsen inntreffer.
Andre etiketter kan også defineres i formatkodede dokumenter. For eksempel kan en rot-etikett (f.eks. "def:Library") bli anvendt for å informere kompilatoren og/eller parseren om å definere underklassen i en separat fil, for å definere underklassen med andre underklasser i én fil og liknende. Det kan dekla-reres et navnerom for et spesialanpasset element, for alle klasser som blir definert innenfor i rot-etiketten og liknende.
Figur 7 illustrerer en hoveddel av et formatkodet dokument som illustrerer et eksempel på syntaks for bruk av en underklasse fra et formatkodet dokument. Dokumentkoden 700 omfatter et rot-element 702 (f.eks. et FlowPanel element), en standardnavnerom-deklarasjon 704, et definisjon-navnerom prefiks 706 og et element 708. En vil forstå at elementet 708 kan referere til en spesial-konstruert komponent som har blitt bygget ved anvendelse av den ovenfor be-skrevne syntaksen. Standardnavnerom-deklarasjonen 704 spesifiserer et standard navnerom for etiketter uten prefiks. I den illustrerte dokumentkoden 700 re-ferer standardnavnerom-deklarasjonen 704 til navnerommet "System.Controls". Definisjon-navnerom prefikset 706 spesifiserer en lokasjon der den spesialkon-struerte komponenten eller elementet kan bli funnet. I den illustrerte dokumentkoden 700 refererer definisjon-navnerom prefikset 706 til "MyControlLib". Elementet 708 omfatter et klassenavn 710 (f.eks. "MyControlLib"), en identifikator 712 og en tekststreng 714. Klassenavnet 710 refererer til den klassen som blir instansiert for dette elementet. Identifikatoren 712 refererer til elementet og omfatter et navn (f.eks. "ID") og en verdi (f.eks. "button 1"). Verdien blir navnet på instansen av klassenavnet 710 ved eksekvering (f.eks. buttonl).
Generalisert operasjon av den forklarende implementasjonen
Figur 8 er et logisk flytdiagram som illustrerer generelt en prosess 800 for å kompilere deklarativt definerte underklasser ifølge én utførelsesform av foreliggende oppfinnelse. Den eksempelvise dokumentkoden som er vist i figurene 4-6, sammen med den motsvarende kildekoden i figur 10, blir anvendt i forbindelse med figur 8 for å beskrive prosessen 800. Som en lett innser, etter å ha sammenliknet figur 10 med dokumentkoden 800, gjør foreliggende oppfinnelse det mulig å generere sofistikerte underklasser på en forklarende måte uten å kreve at utvikleren forstår det underliggende programmeringsspråket. Den representative koden i figur 10 er C# kildekode. Formateringsspråk-kompilatoren, ifølge foreliggende oppfinnelse, kan imidlertid generere representativ kode ved anvendelse av syntaksen til et hvilket som helst programmeringsspråk.
Prosessen 800 begynner i blokk 801, der en formateringsspråk-kompilator kompilerer et formatkodet dokument og møter dokumentkode som omfatter en definisjon av en underklasse. Formateringsspråk-kompilatoren kan avgjøre at den har møtt en underklasse-definisjon ved hjelp av en hvilken som helst mekanisme, så som at den ikke gjenkjenner dokumentkoden som noe annet format, at den kjenner igjen en underklasse-etikett (f.eks. def:Class), og liknende. For eksempel, i dokumentkoden 400, kan formateringsspråk-kompilatoren prosessere flere setninger før den møter den underklasse-etiketten (f.eks. def:Class hintet 410) som identifiserer underklasse-definisjonen. I andre utførel-sesformer kan underklasse-etiketten møtes før andre setninger, for eksempel når underklassen ikke spesifiserer en baseklasse (f.eks. button). Generelt kan underklasse-etiketten dukke opp hvor som helst der en element-etikett kan dukke opp i dokumentkode. Når dokumentkoden detekteres å omfatte en underklasse-definisjon, fortsetter prosesseringen i blokk 802.
I blokk 802 blir underklasse-etiketten prosessert. Som beskrevet i forbindelse med figur 4, blir underklasse-etiketten (også referert til som def:Class hintet 410) tilordnet et navn 414, som også kan omfatte et underklasse-navnerom 412. Basert på denne informasjonen kan det bli generert motsvarende kode, så som linje 1 i figur 10, for assembleringen. I tillegg blir det generert en klasse som har det tilordnede navnet, så som vist i linje 5 i figur 10. Linje 5 vil bli utvidet med annen generert kode straks ytterligere setninger (f.eks. navnerom og baseklasse) er prosessert. Som en del av prosesseringen av underklasse-etiketten, identifiserer prosessen hvorvidt underklassen er avledet fra noen klasse (dvs. en baseklasse), og innhenter informasjon assosiert med baseklassen. I figur 4 er underklassen som blir opprettet, "MyButton", avledet fra "Button", som definert via baseklasse-etiketten 402. Linje 5 i figur 10 omfatter således motsvarende kode som avleder MyButton fra Button som vist.
I tillegg blir det generert en standard konstruktor for underklassen. Igjen, ved prosessering av ytterligere setninger, kan denne standard konstruktoren bli utvidet med ytterligere representativ kode. Linjene 23-24 og 26 i figur 10 svarer til den representative koden som blir generert, "this. lnitialize_This()" er imidlertid kode som blir lagt til etter prosessering av en annen setning, som vil bli beskrevet nedenfor. Når underklassen er prosessert, fortsetter prosesseringen i blokk 804.
I blokk 804 hentes den neste setningen i dokumentkoden. Den neste setningen kan være setningen før eller kan være setningen etter underklasseetikett-setningen avhengig av lokaliseringen av underklasseetikett-setningen innenfor underklasse-definisjonen. Når den neste setningen er lest inn, fortsetter prosesseringen til bestemmelsesblokken 806.
Ved bestemmelsesblokken 806 avgjøres det hvorvidt setningen definerer en klasse. Som nevnt ovenfor, gjør foreliggende oppfinnelse det mulig å uttrykke en klasse på en forklarende måte. I én utførelsesform vil en setning som definerer en annen klasse (dvs. et element) som er en avkommer av underklassen forekomme etter underklasseetikett-setningen. For nå, antatt at den aktu-elle setningen ikke definerer en klasse, fortsetter prosesseringen til blokk 808.
I blokk 808 blir setningen prosessert. Det finnes forskjellige typer setninger som kan forekomme innenfor underklasse-definisjonen. Disse setningene kan forekomme i forskjellig rekkefølge. Prosesseringen involvert for hver type setning vil bli beskrevet nedenfor i detalj. Generelt imidlertid, vil hver setning som blir prosessert resultere i generering av ytterligere motsvarende kode for underklasse-definisjonen. Når én av setningene har blitt prosessert i blokk 808, fortsetter prosesseringen til bestemmelsesblokk 810.
Ved bestemmelsesblokk 810 avgjøres det hvorvidt det er flere setninger som skal prosesseres innenfor underklasse-definisjonen. Dersom det finnes en annen setning, går prosessen tilbake til blokkene 804-808 og prosesserer den setningen. Når alle setningene innenfor underklasse-definisjonen er prosessert, fortsetter prosessen fra bestemmelsesblokk 810 til blokk 812.
I blokk 812 blir den representative koden som har blitt generert under den ovennevnte prosessen anvendt for å generere IL-assembleringene for underklasse-definisjonen. Utvikleren kan ha spesifisert i én av kompilatorhint-setningene (blokk 820) det programmatiske språket som skal anvendes ved generering av den representative koden, kan ha spesifisert i hvilken assembler-fil underklassen skal lagres, og liknende. Når IL-assembleringen eller IL-assembleringene har blitt generert, er prosesseringen komplett. Som nevnt ovenfor er den ovenfor genererte assembler-filen nå tilgjengelig for å bli eksekvert ved anvendelse av tradisjonelle programmeringsspråk, ved anvendelse av formatkodede setninger ifølge foreliggende oppfinnelse, og liknende. Assembler-filen fremtrer som om den skulle være skrevet ved anvendelse av et tradisjonelt programmatisk språk.
Tilbake til bestemmelsesblokk 806, dersom setningen begynner en definisjon av en ny klasse (dvs. et element), fortsetter prosesseringen i blokk 814.1 blokk 814 blir setningene som hører til denne nye klassen prosessert ved anvendelse av prosessering i blokk 808 for hver setning inntil alle setninger som hører til den nye klassen er prosessert. For eksempel, i figur 5, blir setningene 520, 526, 422 prosessert for den nye klassen "Image". Image er da en avkommer fra underklassen "MyButton". Prosessen fortsetter i blokk 804 for å fortsette prosessering av setninger assosiert med underklassen.
Nå, tilbake til blokk 808, skal prosesseringen for hver individuelle type
setning (blokkene 820-832) som kan forekomme innenfor underklasse-definisjonen beskrives. I blokk 820 blir setninger som er kompilatorhint prosessert. Generelt tilveiebringer de setningene som er kompilatorhint informasjon til formateringsspråk-kompilatoren vedrørende hvordan assembler-filen skal genereres. For eksempel, i figur 4, er språkhintet 408 et kompilatorhint som informerer formatteringsspråk-kompilatoren om hvilket programmeringsspråk den skal anvende for å generere den motsvarende koden. I figur 4 er språkhintet 408 satt til C#, og den representative koden illustrert i figur 10 er derfor C# kildekode.
I blokk 822 blir setninger som definerer navnerom prosessert. Disse nav-nerommene blir da inkludert i den representative koden, så som vist i linjene 2 og 3 i figur 10.
I blokk 824 blir setninger som definerer en identifikator (id) for en klasse prosessert. For enhver id-attributt i det formatkodede dokumentet genererer formatteringsspråk-kompilatoren en medlemsvariabel i den assosierte klassen. Medlemsvariabelen blir generert med en type som er den samme som den klassen for hvilken id-attributten er definert. Medlemsvariabelens navn er den id-verdien som er tilordnet id-attributten. For eksempel, i figur 5, under prosessering av de setningene som hører til klassen Image, møtes en id-attributt 520. Som vist i linje 7 i figur 10, vil således formateringsspråk-kompilatoren generere representativ kode for klassen MyButton som har en medlemsvariabel definert som: private System.Comtrols.lmage img1;
Ved kjøretid blir medlemsvariabelen initialisert til en instans av den motsvarende typen (f.eks. Image) som blir opprettet i metoden lnitComponent(). Som resultat av dette kan enhver kode i klassen MyButton aksessere enhver annen elementinstans i sitt hierarki bare med klassens id-verdi. Initialiseringen av medlemsvariabelen er vist i linje 37 i figur 10.
I blokk 826 blir setninger som definerer en egenskap for en klasse prosessert. For enhver egenskap som er definert i det formatkodede dokumentet, genererer formateringsspråk-kompilatoren motsvarende kildekode for egenskapen og registrerer egenskapen dersom det er nødvendig. For eksempel, i figur 6, inkluderer dokumentkoden 600 et egenskap-hint 610 som har forskjellige attributter 612-618. Egenskap-hintet 610 vil informere formateringsspråk-kompilatoren om at setningene som følger etter egenskap-hintet 610 er for en egenskap. Attributene 612-618 blir da lest inn som egenskap-setninger. Formateringsspråk-kompilatoren vil generere motsvarende kode for "Label"-egenskapen for å registrere egenskapen for klassen MyButton som vist i linjene 9-12 i figur 10. Formateringsspråk-kompilatoren vil også generere motsvarende kode for å definere egenskapen som vist i linjene 28-30 i figur 10. Linjene 28-30 illustrerer hvordan navn-attributten 612 blir egenskapens navn i den motsvarende koden og type-attributten blir egenskapens type i den motsvarende koden.
I én utførelsesform genererer prosessen kode for egenskapens verdier ved å kalle TypeConverter for egenskapens type, som eksekverer kode ved kjø-retid ved anvendelse av refleksjon og konverterer strengen til en faktisk objekt-instans av egenskapens type. I en annen utførelsesform kaller prosessen 800 type-konvertereren for egenskapen for å oppnå den faktiske objektverdien og konverterer verdien til et InstanceDescriptor-objekt. InstanceDescriptor-objektet inneholder tilstrekkelig informasjon, slik at formateringsspråk-kompilatoren basert på objektet kan generere representativ kode som oppretter en ny instans av verdiens type som spesifisert i attributtene assosiert med egenskap-hintet. Linjene 28-30 i figur 19 illustrerer hvordan labelProperty vil bli satt for en instans av MyButton under kjøretid med den tilordnede verdien for Label-egenskapen. Den tilordnede verdien kan være tilordnet på forklarende måte i dokumentkode (som vist i figur 7) eller tilordnet programmatisk ved anvendelse av et hvilket som helst programmeringsspråk.
I blokk 828 blir setninger som definerer en hendelse for en klasse prosessert. For hendelse-setninger genererer formateringsspråk-kompilatoren motsvarende kode for hendelsen. Hendelser kan bli definert i dokumentkode ved anvendelse av forskjellige mulige mekanismer, så som en hendelse-attributt 526 vist i figur 5 og som et hendelse-hint 620 vist i figur 6. Først vil mekanismen som anvender hendelse-attributten bli beskrevet. Hendelse-attributten omfatter hendelse-triggeren og hendelse-verdien. Hendelse-triggeren svarer til hendelsen og hendelse-verdien svarer til den funksjonen som blir eksekvert når hendelse-triggeren aktiveres. Med henvisning til figur 5 blir hendelse-verdien 529 ("OnLoaded") lagt til som en hendelsehåndterer i linjene 38-40 i den motsvarende koden i figur 10 ved å definere "this.Onloaded" som den nye System.Controls.DataLoadedEventHandler. Hendelse-triggeren 527 ("DataLoaded") blir lagt til som hendelsen i linje 38 i den motsvarende koden i figur 10 ved å definere den første parameteren til AddHandler som System.Controls.lmage.DataLoadedEvent. Den andre parameteren for AddHandler kan anvende standardverdier eller kan være spesifisert i dokumentkoden.
Mekanismen som anvender hendelse-hintet 620 vil nå bli beskrevet. Hendelse-hintet 620 omfatter en hendelsenavn-attributt og andre attributter. Navnet som er tilordnet hendelsenavn-attributten blir registrert som hendelsen. For eksempel, med henvisning til figur 6, er "DblClick" navnet som er tilordnet hendelsenavn-attributten. "DblClick" er derfor den første parameteren i metoden RegisterEvent som blir generert i linjene 14-16 i figur 10. Typen til hendelsehåndterer-deklarasjonen 630 for metoden "DblClickEventHdlr" er også inkludert som en parameter i metoden RegisterEvent i figur 10. Igjen kan de andre para-meterne til metoden RegisterEvent anvende standardverdier eller kan være spesifisert i det formatkodede dokumentet ved anvendelse av andre attributter. Ved kjøretid, ifølge én utførelsesform, blir hendelsen innkoplet ved anvendelse av refleksjon for å identifisere typen av DblClickEventHandler og for å lokalisere metoden.
I blokk 830 blir setninger som definerer kode prosessert. Setninger som definerer kode etterfølger en kompilatorhint-setning (blokk 820), så som kodehint. Disse setningene er skrevet i et programmeringsspråk og vil bli inkludert som de er i den motsvarende koden. For eksempel illustrerer figur 5 metoden 530 og funksjonen Customlnit 550. Metoden 530 og funksjonen Customlnit 550 befinner seg henholdsvis i linjene 18-19 og 21 i figur 10.
I blokk 832 blir setninger som definerer en supplerende konstruktør prosessert. Igjen etterfølger setninger som definerer en supplerende konstruktør en kompilatorhint-setning (blokk 820), så som konstruktør-hint. Formateringsspråk-kompilatoren genererer en supplerende konstruktør ("this. lnitialize_This()" i figur 10) og legger til setningene i den supplerende konstruktøren. For eksempel, i figur 5, kaller setningen etter konstruktør-hintet 542 "CustomlnitO". I figur 10 i linje 33 legger således formateringsspråk-kompilatoren til "CustomlnitO i den supplerende konstruktøren i den motsvarende kildekoden.
Fagmannen vil forstå at blokk 812 kan bli utført stegvis under prosessering i boksene 804-810 uten å avgå fra foreliggende oppfinnelse. I tillegg, avhengig av den funksjonelle implementasjonen av parser 204 og formateringsspråk-kompilator 202, kan det være tilbakekall mellom parser 204 og formateringsspråk-kompilator 202 under prosessen 800.
Figur 9 er et logisk flytdiagram som illustrerer generelt en kjøreprosess 900 for å anvende en underklasse som har blitt deklarert fra inne i et formatkodet dokument ifølge én utførelsesform av foreliggende oppfinnelse. Dokument-kodeeksempelet som er vist i figur 7 blir anvendt i forbindelse med figur 9 for å beskrive prosessen 900. Prosessen 900 begynner i blokk 901, der en kjøremo-tor mottar en forespørsel om en gitt ressurs (f.eks. et formatkodet dokument) og bestemmer at det eksisterer en kompilert versjon av den gitte ressursen. For eksempel, i figur 7, antatt at dokumentkoden 700 ikke allerede har blitt kompilert til en symbolbasert binærfil, når formateringsspråk-kompilatoren møter på elementet 708, vil formateringsspråk-kompilatoren detektere at klassen MyButton har en assosiert symbolbasert binærfil og IL-assemblering. Denne assosierte, symbolbaserte binærfilen som inkluderer de symboliserte attributtene for klassen MyButton vil da bli prosessert ved anvendelse av prosessen 900. Den assosierte, symbolbaserte binærfilen og IL-assembleringen kan være generert under anvendelse av foreliggende oppfinnelse. Prosesseringen fortsetter i blokk 902.
I blokk 902 blir den symbolbaserte binærfilen lastet. Den symbolbaserte binærfilen kan bli lastet stegvis eller i sin helhet. Den symbolbaserte binærfilen kan identifisere IL-assembleringer assosiert med den symbolbaserte binærfilen som må lastes. Med henvisning til figur 7, for eksempel, blir de IL-assembleringene som er assosiert med klassen MyButton lastet. Prosesseringen fortsetter i blokk 904.
I blokk 904 blir et symbol hentet fra den symbolbaserte binærfilen. Som nevnt ovenfor, i det nye kjøremiljøet, er den symbolbaserte binærfilen som blir generert uavhengig av hvilket programmeringsspråk som ble anvendt for å generere den symbolbaserte binærfilen. Kjøremotoren kan således prosessere den symbolbaserte binærfilen uten hensyn til hvilket programmeringsspråk som opprinnelig ble anvendt for å skape den symbolbaserte binærfilen. Prosesseringen fortsetter ved bestemmelsesblokk 906.
Ved bestemmelsesblokk 906 avgjøres det hvorvidt symbolet som ble inn-hentet er en hendelse. Dersom symbolet ikke er en hendelse, fortsetter prosesseringen i blokk 908.
I blokk 908 blir symbolet prosessert. Som nevnt ovenfor avhenger ikke prosesseringen av symbolet av måten på hvilken den symbolbaserte binærfilen har blitt generert. Med andre ord vil symbolprosesseringen av et symbol i en symbolbasert binærfil som har blitt opprettet på en forklarende måte i et formatkodet dokument eller ved anvendelse av et programmeringsspråk fortsette på samme måte. Derfor, ettersom prosessering av symboler i en symbolbasert binærfil kjent for fagmannen, trenger ikke prosesseringen av symbolet å bli beskrevet utførlig her. Prosesseringen fortsetter ved bestemmelsesblokk 910.
Ved bestemmelsesblokk 910 avgjøres det hvorvidt det er flere symboler i den symbolbaserte binærfilen. Dersom det er flere symboler, går prosessen tilbake til blokk 904 og fortsetter som beskrevet ovenfor. På den annen side, dersom det ikke finnes flere symboler, er prosesseringen fullført og fortsetter til slutt-blokken.
Tilbake til bestemmelsesblokk 906, dersom symbolet er en hendelse, fortsetter prosesseringen i blokk 912.1 blokk 912 blir metadata assosiert med den symbolbaserte binærfilen lastet. Metadataene omfatter beskrivelser av typer, ressurser, metoder og liknende. Prosesseringen fortsetter i blokk 914.
I blokk 914, ved anvendelse av metadata og refleksjon, finner prosessen en mål-elementtype for hendelsen. Dette involverer det å aksessere metadataene og gå gjennom hvert felt for å bestemme typen. Prosesseringen fortsetter i blokk 916.
I blokk 916 blir hendelsen validert med hensyn til mål-elementtypen. Dette sikrer at hendelsen er en gyldig hendelse. Dersom hendelsen ikke er en gyldig hendelse for mål-elementtypen, rapporteres en feil. Prosesseringen fortsetter i blokk 918.
I blokk 918 anvendes refleksjon over mål-elementtypen for å oppnå hendelsemetoden, som deretter blir eksekvert. Det å eksekvere hendelsemetoden
omfatter det å eksekvere kode i den assosierte IL-assembleringen. Med henvisning til figur 7, når MyButton blir instansiert og hendelsen er funnet, blir således hendelsemetoden ("DblClickEvent") tilknyttet. Dette knytter en hendelsehåndterer (f.eks. DblClickEventHandler) til hendelsen (f.eks. DblClick). Prosesseringen fortsetter ved bestemmelsesblokk 910 og forløper som beskrevet ovenfor,
Som beskrevet tilveiebringer således foreliggende oppfinnelse en mekanisme for forklarende definering av underklasser i et formatkodet dokument og for anvendelse av underklasser fra et formatkodet dokument. Dette gjør at utviklere kan fokusere mer på måter å anvende komponentene i stedet for å be-kymre seg for hvordan de skal implementere komponentene i et programmeringsspråk.
Spesifikasjonen, eksemplene og dataene ovenfor tilveiebringer en komplett beskrivelse av opprettelse og anvendelse av sammensetningen ifølge oppfinnelsen. Ettersom mange utførelsesformer av oppfinnelsen er mulige innenfor idéen bak og rammen til oppfinnelsen, defineres oppfinnelsen av de etterfølg-ende patentkravene.
Claims (39)
1. Datamaskinlesbart medium innkodet med en datamaskinlesbar datastruktur, der datastrukturen omfatter: et skjema for forklarende definering av en underklasse-definisjon i et formatkodet dokument, idet skjemaet kan bli kompilert til en eksekverbar assemblering som instansierer et objekt som er assosiert med en underklasse som er definert innenfor underklasse-definisjonen ved eksekvering av assembleringen, hvor den eksekverbare assemblering er uavhengig av et programmeringsspråk som opprinnelig er benyttet for å skape assembleringen slik at den eksekverbare sammenstillingen er kompilert uten hensyn til programmeringsspråket.
2. Datamaskinlesbart medium ifølge krav 1, der skjemaet er et XML (Extensible Markup Language) - basert skjema.
3. Datamaskinlesbart medium ifølge krav 1, der skjemaet omfatter en underklasse-etikett for å definere et navn, idet navnet er assosiert med en type for objektet som blir instansiert.
4. Datamaskinlesbart medium ifølge krav 1, der skjemaet omfatter et språk-hint for å spesifisere et programmeringsspråk å anvende ved kompilering av underklasse-definisjonen.
5. Datamaskinlesbart medium ifølge krav 4, der skjemaet videre omfatter et kodehint for å innlemme kode i det formatkodede dokumentet, idet koden blir kompilert direkte inn i den eksekverbare assembleringen.
6. Datamaskinlesbart medium ifølge krav 5, der koden blir kompilert direkte basert på en syntaks for det programmeringsspråket som er spesifisert i språkhintet.
7. Datamaskinlesbart medium ifølge krav 1, der skjemaet omfatter et baseklasse-hint for å spesifisere en baseklasse fra hvilken underklassen er avledet.
8. Datamaskinlesbart medium ifølge krav 7, der skjemaet omfatter en base-klassenavnerom-attributt for å spesifisere et navnerom i hvilket baseklassen befinner seg.
9. Datamaskinlesbart medium ifølge krav 1, der skjemaet omfatter en underklasse-etikett for å spesifisere underklassen.
10. Datamaskinlesbart medium ifølge krav 1, der skjemaet omfatter et kon-struktør-hint for å spesifisere én eller flere supplerende handlinger å utføre ved instansiering av et objekt.
11. Datamaskinlesbart medium ifølge krav 1, der skjemaet omfatter et hendelse-hint for å spesifisere en hendelse og en tilhørende hendelsehåndterer som assosieres med objektet når det blir instansiert.
12. Datamaskinlesbart medium ifølge krav 1, der skjemaet omfatter et egenskap-hint for å spesifisere en egenskap, idet egenskapen blir en medlemsvariabel i objektet når objektet blir instansiert.
13. Datamaskinlesbart medium ifølge krav 1, der skjemaet omfatter en ele-mentdeklarasjon for å spesifisere et avkommerelement av underklassen.
14. Datamaskinlesbart medium som inneholder instruksjoner for å generere en eksekverbar assemblering for en underklasse, der instruksjonene omfatter det å: identifisere en underklasse-definisjon i et formatkodet dokument, idet underklasse-definisjonen definerer en underklasse; og generere en assemblering basert på underklasse-definisjonen, idet assembleringen kan bli eksekvert for å opprette en instans av et objekt assosiert med underklassen, hvor den genererte assemblering er uavhengig av et programmeringsspråk som opprinnelig er benyttet for å skape assembleringen slik at den genererte sammenstillingen er eksekvert uten hensyn til programmeringsspråket.
15. Datamaskinlesbart medium ifølge krav 14, der det å identifisere underklasse-definisjonen omfatter det å parsere en underklasse-etikett, der underklasse-etiketten omfatter en underklassenavn-attributt for å definere et navn, idet navnet er assosiert med en type for objektet som blir instansiert.
16. Datamaskinlesbart medium ifølge krav 14, der det å generere en assemblering basert på underklasse-definisjonen omfatter det å kompilere underklasse-definisjonen til motsvarende kildekode som blir kompilert inn i assembleringen.
17. Datamaskinlesbart medium ifølge krav 16, der den motsvarende kildekoden er basert på et programmatisk språk.
18. Datamaskinlesbart medium ifølge krav 14, der det å generere en assemblering basert på underklasse-definisjonen omfatter det å kompilere kode innenfor underklasse-definisjonen inn i assembleringen, idet koden blir innlemmet direkte i underklasse-definisjonen av et kodehint.
19. Datamaskinlesbart medium ifølge krav 14, der det å generere en assemblering basert på underklasse-definisjonen omfatter det å parsere en baseklasse-etikett som definerer en baseklasse fra hvilken underklassen skal avledes, spesifisere arven ved anvendelse av en syntaks assosiert med et programmatisk språk, samt kompilere syntaksen til å bli en del av assembleringen.
20. Datamaskinlesbart medium ifølge krav 14, der det å generere en assemblering basert på underklasse-definisjonen omfatter det å parsere et konstruk-tør-hint som definerer minst én supplerende handling som blir utført når objektet instansieres, idet den supplerende handlingen er en del av assembleringen.
21. Datamaskinlesbart medium ifølge krav 14, der det å generere en assemblering basert på underklasse-definisjonen omfatter det å parsere et hendelse-hint som oppretter en hendelse-definisjon og en tilhørende hendelsehåndterer for underklassen.
22. Datamaskinlesbart medium ifølge krav 14, der det å generere en assemblering basert på underklasse-definisjonen omfatter det å parsere et egenskap-hint som definerer en egenskap som blir en medlemsvariabel i objektet når objektet blir instansiert.
23. Datamaskinlesbart medium ifølge krav 14, der det å generere en assemblering basert på underklasse-definisjonen omfatter det å parsere en element-deklarasjon-etikett som definerer et avkommerelement av underklassen.
24. Datamaskin-implementert fremgangsmåte for å generere en eksekverbar assemblering, idet fremgangsmåten omfatter det å: identifisere en underklasse-definisjon i et formatkodet dokument, der underklasse-definisjonen definerer en underklasse; og generere en assemblering basert på underklasse-definisjonen, idet assembleringen kan eksekveres for å opprette en instans av et objekt assosiert med underklassen, hvor den genererte assemblering er uavhengig av et programmeringsspråk som opprinnelig er benyttet for å skape assembleringen slik at den genererte sammenstillingen er eksekvert uten hensyn til programmeringsspråket.
25. Datamaskin-implementert fremgangsmåte ifølge krav 24, der det å identifisere underklasse-definisjonen omfatter det å parsere en underklasse-etikett, der underklasse-etiketten omfatter en underklassenavn-attributt for å definere et navn, idet navnet assosieres med en type for objektet som instansieres.
26. Datamaskin-implementert fremgangsmåte ifølge krav 24, der det å generere en assemblering basert på underklasse-definisjonen omfatter det å parsere en baseklasse-etikett som definerer en baseklasse fra hvilken underklassen avledes, spesifisere arven ved anvendelse av en syntaks som er basert på et programmatisk språk, samt kompilere syntaksen til å bli en del av assembleringen.
27. Datamaskin-implementert fremgangsmåte ifølge krav 24, der det å generere en assemblering basert på underklasse-definisjonen omfatter det å parsere et konstruktør-hint som definerer minst én supplerende handling som utføres når objektet instansieres, idet den supplerende handlingen er en del av assembleringen.
28. Datamaskin-implementert fremgangsmåte ifølge krav 24, der det å generere en assemblering basert på underklasse-definisjonen omfatter det å parsere et hendelse-hint som oppretter en hendelse-definisjon og en tilhørende hendelsehåndterer for underklassen.
29. Datamaskin-implementert fremgangsmåte ifølge krav 24, der det å generere en assemblering basert på underklasse-definisjonen omfatter det å parsere et egenskap-hint som definerer en egenskap som er en medlemsvariabel i objektet når objektet instansieres.
30. Datamaskinlesbart medium som omfatter instruksjoner for å skape en eksekverbar assemblering for en underklasse, idet instruksjonene omfatter fremgangsmåte ifølge krav 24.
31. Datasystem for å generere en assemblering fra en underklasse-definisjon med et formatkodet dokument, der datasystemet omfatter: en prosessor; og et minne, der minnet er allokert forflere datamaskin-eksekverbare instruksjoner som blir lastet inn i minnet, hvor prosessoren eksekverer instruksjonene for å: identifisere en underklasse-definisjon i et formatkodet dokument, idet underklasse-definisjonen definerer en underklasse; og generere en assemblering basert på underklasse-definisjonen, idet assembleringen kan bli eksekvert for å opprette en instans av et objekt assosiert med underklassen, hvor den genererte assemblering er uavhengig av et programmeringsspråk som opprinnelig er benyttet for å skape assembleringen slik at den genererte sammenstillingen er eksekvert uten hensyn til programmeringsspråket.
32. Datamaskin-implementert fremgangsmåte ifølge krav 31, der det å identifisere underklasse-definisjonen omfatter det å parsere en underklasse-etikett, der underklasse-etiketten omfatter en underklassenavn-attributt for å definere et navn, idet navnet assosieres med en type for objektet som blir instansiert.
33. Datamaskin-implementert fremgangsmåte ifølge krav 31, der det å generere en assemblering basert på underklasse-definisjonen omfatter det å parsere et konstruktør-hint som definerer minst én supplerende handling som utføres når objektet instansieres, idet den supplerende handlingen er en del av assembleringen.
34. Datamaskin-implementert fremgangsmåte ifølge krav 31, der det å generere en assemblering basert på underklasse-definisjonen omfatter det å parsere et hendelse-hint som oppretter en hendelse-definisjon og en tilhørende hendelsehåndterer for underklassen.
35. Datamaskin-implementert fremgangsmåte ifølge krav 31, der det å generere en assemblering basert på underklasse-definisjonen omfatter det å parsere et egenskap-hint som definerer en egenskap som er en medlemsvariabel i objektet når objektet blir instansiert.
36. Datamaskin-implementert fremgangsmåte for å generere en eksekverbar assemblering, idet fremgangsmåten omfatter: et middel for å identifisere en underklasse-definisjon i et formatkodet dokument, der underklasse-definisjonen definerer en underklasse; og et middel for å generere en assemblering basert på underklasse-definisjonen, der assembleringen kan eksekveres for å opprette en instans av et objekt assosiert med underklassen, hvor den genererte assemblering er uavhengig av et programmeringsspråk som opprinnelig er benyttet for å skape assembleringen slik at den genererte sammenstillingen er eksekvert uten hensyn til programmeringsspråket.
37. Datamaskin-implementert fremgangsmåte ifølge krav 36, der middelet for å identifisere underklasse-definisjonen omfatter et middel for å parsere en underklasse-etikett, idet underklasse-etiketten omfatter en underklassenavn-attributt for å definere et navn, og navnet assosieres med en type for objektet som blir instansiert.
38. Datamaskin-implementert fremgangsmåte ifølge krav 36, der middelet for å generere en assemblering basert på underklasse-definisjonen omfatter en måte for å parsere en baseklasse-etikett som definerer en baseklasse fra hvilken underklassen avledes, et middel for å spesifisere arven ved anvendelse av en syntaks som er basert på et programmatisk språk, samt en måte for å kompilere syntaksen til å bli en del av assembleringen.
39. Datamaskin-implementert fremgangsmåte ifølge krav 36, der middelet for å generere en assemblering basert på underklasse-definisjonen omfatter et middel for å parsere et konstruktør-hint som definerer minst én supplerende handling som utføres når objektet instansieres, idet den supplerende handlingen er en del av assembleringen.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US10/377,313 US7120618B2 (en) | 2003-02-28 | 2003-02-28 | System and method for defining and using subclasses declaratively within markup |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| NO20032232D0 NO20032232D0 (no) | 2003-05-16 |
| NO20032232L NO20032232L (no) | 2004-08-30 |
| NO329240B1 true NO329240B1 (no) | 2010-09-20 |
Family
ID=23488596
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| NO20032232A NO329240B1 (no) | 2003-02-28 | 2003-05-16 | System og fremgangsmate for forklarende definering og bruk av undergrupper innenfor dokumentkoding |
Country Status (15)
| Country | Link |
|---|---|
| US (1) | US7120618B2 (no) |
| EP (1) | EP1452962B1 (no) |
| JP (1) | JP4806158B2 (no) |
| KR (2) | KR100889671B1 (no) |
| CN (1) | CN100454244C (no) |
| AU (1) | AU2003204197B2 (no) |
| BR (1) | BR0301738A (no) |
| CA (1) | CA2428558C (no) |
| HK (1) | HK1066616A1 (no) |
| MX (1) | MXPA03004411A (no) |
| MY (1) | MY136473A (no) |
| NO (1) | NO329240B1 (no) |
| RU (1) | RU2347269C2 (no) |
| TW (1) | TWI327701B (no) |
| ZA (1) | ZA200303680B (no) |
Families Citing this family (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7418659B2 (en) * | 2003-02-28 | 2008-08-26 | Microsoft Corporation | System and method for declaring a resource within a markup document |
| US7725884B2 (en) * | 2003-02-28 | 2010-05-25 | Microsoft Corporation | System and method for compiling markup files |
| US7890928B2 (en) * | 2003-07-26 | 2011-02-15 | Pilla Gurumurty Patrudu | Mechanism and system for representing and processing rules |
| US20050154978A1 (en) * | 2004-01-09 | 2005-07-14 | International Business Machines Corporation | Programmatic creation and access of XML documents |
| US20070136658A1 (en) * | 2005-11-29 | 2007-06-14 | International Business Machines Corporation | Handling events in a descriptive context |
| US9128727B2 (en) * | 2006-08-09 | 2015-09-08 | Microsoft Technology Licensing, Llc | Generation of managed assemblies for networks |
| US8380742B2 (en) * | 2006-10-10 | 2013-02-19 | Microsoft Corporation | Integration of database reporting with ERP systems |
| US7765241B2 (en) * | 2007-04-20 | 2010-07-27 | Microsoft Corporation | Describing expected entity relationships in a model |
| US8880564B2 (en) * | 2007-10-11 | 2014-11-04 | Microsoft Corporation | Generic model editing framework |
| US7530060B1 (en) * | 2008-01-08 | 2009-05-05 | International Business Machines Corporation | Methods and computer program product for optimizing binaries with coding style formalization |
| US9584877B2 (en) * | 2011-06-16 | 2017-02-28 | Microsoft Technology Licensing, Llc | Light-weight validation of native images |
| US9015661B1 (en) * | 2011-06-23 | 2015-04-21 | The Mathworks, Inc. | Restricting class inheritance relationships |
| US9158505B2 (en) * | 2014-01-09 | 2015-10-13 | Microsoft Technology Licensing, Llc | Specifying compiled language code in line with markup language code |
| US20240111555A1 (en) * | 2022-10-04 | 2024-04-04 | International Business Machines Corporation | Unknown object sub-class identification |
Family Cites Families (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6083276A (en) * | 1998-06-11 | 2000-07-04 | Corel, Inc. | Creating and configuring component-based applications using a text-based descriptive attribute grammar |
| US6342907B1 (en) | 1998-10-19 | 2002-01-29 | International Business Machines Corporation | Specification language for defining user interface panels that are platform-independent |
| US6427228B1 (en) * | 1999-05-12 | 2002-07-30 | International Business Machines Corporation | Combining a meta data file and java source code to dynamically create java classes and javabeans |
| US6732330B1 (en) * | 1999-09-30 | 2004-05-04 | International Business Machines Corporation | Scripting language blocks to support multiple scripting languages in a single web page |
| GB0011426D0 (en) * | 2000-05-11 | 2000-06-28 | Charteris Limited | A method for transforming documents written in different XML-based languages |
| US6941510B1 (en) * | 2000-06-06 | 2005-09-06 | Groove Networks, Inc. | Method and apparatus for efficient management of XML documents |
| US6957394B1 (en) * | 2000-12-01 | 2005-10-18 | Microsoft Corporation | Rendering controls of a web page according to a theme |
| US20020091818A1 (en) * | 2001-01-05 | 2002-07-11 | International Business Machines Corporation | Technique and tools for high-level rule-based customizable data extraction |
| KR20020061888A (ko) * | 2001-01-18 | 2002-07-25 | 박철만 | 엑스엠엘 응용프로그램의 개발방법 |
| US20030037311A1 (en) * | 2001-08-09 | 2003-02-20 | Busfield John David | Method and apparatus utilizing computer scripting languages in multimedia deployment platforms |
| US20040064826A1 (en) * | 2002-09-30 | 2004-04-01 | Timothy Lim | Method and system for object system interoperability |
| US20040064825A1 (en) * | 2002-09-30 | 2004-04-01 | Timothy Lim | Method and system for object system interoperability |
-
2003
- 2003-02-28 US US10/377,313 patent/US7120618B2/en not_active Expired - Fee Related
- 2003-05-13 MY MYPI20031785A patent/MY136473A/en unknown
- 2003-05-13 CA CA2428558A patent/CA2428558C/en not_active Expired - Fee Related
- 2003-05-13 ZA ZA200303680A patent/ZA200303680B/xx unknown
- 2003-05-14 AU AU2003204197A patent/AU2003204197B2/en not_active Ceased
- 2003-05-16 RU RU2003114535/09A patent/RU2347269C2/ru not_active IP Right Cessation
- 2003-05-16 NO NO20032232A patent/NO329240B1/no not_active IP Right Cessation
- 2003-05-16 BR BR0301738-9A patent/BR0301738A/pt not_active IP Right Cessation
- 2003-05-16 TW TW092113389A patent/TWI327701B/zh not_active IP Right Cessation
- 2003-05-17 KR KR1020030031428A patent/KR100889671B1/ko not_active IP Right Cessation
- 2003-05-19 CN CNB03136764XA patent/CN100454244C/zh not_active Expired - Fee Related
- 2003-05-19 MX MXPA03004411A patent/MXPA03004411A/es active IP Right Grant
- 2003-05-19 JP JP2003141202A patent/JP4806158B2/ja not_active Expired - Fee Related
- 2003-05-19 EP EP03011353.4A patent/EP1452962B1/en not_active Expired - Lifetime
-
2004
- 2004-12-02 HK HK04109550.9A patent/HK1066616A1/xx not_active IP Right Cessation
-
2009
- 2009-02-05 KR KR1020090009463A patent/KR100942322B1/ko not_active IP Right Cessation
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004265371A (ja) | 2004-09-24 |
| TWI327701B (en) | 2010-07-21 |
| KR100889671B1 (ko) | 2009-03-19 |
| KR20040077410A (ko) | 2004-09-04 |
| KR100942322B1 (ko) | 2010-02-12 |
| AU2003204197B2 (en) | 2009-10-01 |
| AU2003204197A1 (en) | 2004-09-16 |
| NO20032232L (no) | 2004-08-30 |
| CA2428558A1 (en) | 2004-08-28 |
| MXPA03004411A (es) | 2005-08-26 |
| US7120618B2 (en) | 2006-10-10 |
| RU2347269C2 (ru) | 2009-02-20 |
| EP1452962A2 (en) | 2004-09-01 |
| NO20032232D0 (no) | 2003-05-16 |
| TW200416569A (en) | 2004-09-01 |
| CA2428558C (en) | 2013-01-22 |
| CN100454244C (zh) | 2009-01-21 |
| JP4806158B2 (ja) | 2011-11-02 |
| EP1452962B1 (en) | 2018-01-24 |
| KR20090024229A (ko) | 2009-03-06 |
| EP1452962A3 (en) | 2007-01-10 |
| CN1525317A (zh) | 2004-09-01 |
| HK1066616A1 (en) | 2005-03-24 |
| MY136473A (en) | 2008-10-31 |
| US20040172617A1 (en) | 2004-09-02 |
| ZA200303680B (en) | 2004-08-13 |
| BR0301738A (pt) | 2004-10-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR100995199B1 (ko) | 명령에 입력되는 파라미터들에 반영 기반 프로세싱을 수행하는 시스템 및 컴퓨터 판독 가능 저장 매체 | |
| CN105164641B (zh) | 扩展开发环境 | |
| US9471282B2 (en) | System and method for using annotations to automatically generate a framework for a custom javaserver faces (JSF) component | |
| KR100942322B1 (ko) | 마크업 내부에서 명시적으로 서브클래스를 정의하고 이용하는 시스템 및 방법 | |
| CN110704063B (zh) | 编译和执行智能合约的方法及装置 | |
| KR101099173B1 (ko) | 소프트웨어 스위트를 구축하기 위한 시스템 및 방법 | |
| CN110688122B (zh) | 编译和执行智能合约的方法及装置 | |
| US20080127060A1 (en) | Dynamic mating of a modified user interface with pre-modified user interface code library | |
| US8141035B2 (en) | Method for accessing internal states of objects in object oriented programming | |
| US20090319554A1 (en) | Unified metadata for external components | |
| Bolin | Closure: The definitive guide: Google tools to add power to your JavaScript | |
| JP6845429B2 (ja) | コンパイラプログラム、情報処理装置およびコンパイル方法 | |
| US7530075B2 (en) | System and method for employing object-based pipelines | |
| US20110296373A1 (en) | Command line shell command generation based on schema | |
| Boujarwah et al. | Testing syntax and semantic coverage of Java language compilers | |
| Lang et al. | Package ‘xml’ | |
| US8453108B1 (en) | Static, configurable kernel interface | |
| Pawlan | Writing Enterprise Applications with Java™ 2 SDK, Enterprise Edition | |
| Shatnawi et al. | Rapport de recherche Latece 2017-4 The Codification of Program Dependencies of JSP Custom Tag Libraries in JEE Applications | |
| Sells et al. | ATL internals: working with ATL 8 | |
| Pandolfo et al. | A Framework for Adding Design by ContractTM to the. NET Object-Oriented Programming Languages. | |
| Churcher et al. | Object Oriented Metrics: Precision Tools and Configurable Visualisations | |
| Ghosh et al. | Application Design and Programming Model |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| CHAD | Change of the owner's name or address (par. 44 patent law, par. patentforskriften) |
Owner name: MICROSOFT TECHNOLOGY LICENSING, US |
|
| MM1K | Lapsed by not paying the annual fees |