KR20010106514A - Method and system for an extensible macro language - Google Patents

Abstract

A method and system for an extensible macro language is provided. The system for providing the extensible macro language includes a parser and a macro handler for processing macro commands not previously defined in the macro language. The parser analyzes keywords in a macro language expression and recognizes one or more keywords representing macro commands that were not previously defined in the macro language. The macro handler receives the keywords in the macro expression and retrieves from a registry of keywords, an executable code or procedure associated with the keyword. The executable code is run to process the macro command represented by the keyword. The template language registry may be augmented to include any keywords and associated codes for extending the macro language.

Description

METHOD AND SYSTEM FOR AN EXTENSIBLE MACRO LANGUAGE}

A macro is a series of instructions that can be played back to perform a given task. Examples of such tasks include inserting a commonly used name and address into a word processor or performing a series of keystrokes to format a file. Tasks performed with macros are typically repeated in a property that makes it possible to significantly reduce time by executing macros instead of manually repeating commands.

Currently, different applications allow users to record macros and scripts within the scope of the allowed area, ie within the scope of a particular application. For example, a processor typically allows a user to create a macro by recording a series of keystrokes to be reproduced later. Other applications allow users to write macros to retrieve and manipulate data within the scope of the application. Therefore, such applications include a limited set of macros, such as macros for recording keystrokes, and macros for retrieving data. The user is usually limited to macros provided by the application program.

Often, however, a user using an application has a specific set of instructions or commands that the user wants to include as a macro in an application that is not provided in advance. Macros are usually hard coded in the application or macro language included in the application, so the only available method currently available to include additional macros in the application is to modify the source code and recompile it before the new macro is available. By hard coding new macros in your application. However, this is usually a problem because the user is not given access to the source code of the application or macro language to be modified. In addition, it would be a heavy burden for application developers to customize their applications to include the macros they want to have, to suit individual user preferences.

Therefore, it is highly desirable to have an extensible macro language that allows the user to modify and extend the language to include the user's preferences when using the macro language. In addition, it is highly desirable to allow macros to be extended without modifying or accessing the source code of the macro language because the user is treated as a patent feature that the source code is not distributed to the user.

This application enjoys the benefit of the filing date of US Patent Application No. 60 / 104,682, entitled Modeling Tools System and Method, filed October 16,1998.

This application is related to co-pending U. S. Patent No. 60 / 104,682, which is a method for determining differences between two or more models whose name is filed herein as incorporated by reference.

This application is related to co-pending U.S. Patent No. 60 / 104,682, the name of the invention filed as the same hereby incorporated by reference, which is a method for impact analysis of the model.

This application is related to co-pending U.S. Patent No. 60 / 104,682, which is a method and apparatus for providing access to hierarchical data storage via SQL input, the name of which is hereby incorporated by reference. have.

This application is related to co-pending U. S. Patent No. 60 / 104,682, entitled Apparatus and Method for Modeling Tools, of which the invention is filed hereby, which is hereby incorporated by reference.

The present invention relates generally to computer language processors, and more particularly to extensible macro languages.

Best Mode for Carrying Out the Invention A preferred embodiment of the present invention will be described with reference to the accompanying drawings in the illustration.

1 is a block diagram illustrating the components of an extensible macro language of the present invention.

2 shows an example of a macro representation with an iterator macro.

To overcome the drawbacks of the macro language processor of the prior art described above, the present invention provides an extension that enables a user to write a new macro instruction that includes procedures tailored to the user's specific needs without having to modify the source code of the macro language processor. Provides a macro language where possible. The extensible macro language recognizes new macro commands that do not know the language and associates the new macro commands with the procedure calls stored in the registry, namely the repository, and the new macro commands, allowing for the dynamic expansion of the macro language. .

In the present invention, a mechanism for dynamically registering a new macro command in the registry is also provided to be extensible. To register a new macro command, a user can insert a keyword and associated code or procedure into the registry representing a new macro command for execution by an extensible macro language.

The present invention also defines a simple syntax for an extended macro language to recognize new macro commands without having to know what function the new macro command performs.

According to an object of the present invention, there is provided a macro handler and parser for processing macro instructions not defined in advance in a macro language. Macro commands that are not predefined or undefined in a macro language refer to macro commands that are not included in the set of commands available in the macro language at the time of distribution or release to a user. The parser analyzes keywords in macro language representation and recognizes one or more keywords that represent macro commands that are not predefined in macro language. The macro handler receives the keyword as a macro representation and retrieves the executable code associated with the keyword from the keyword's registry. Executable code is executed to process macro instructions represented by keywords. The registry of keywords can be increased to include relevant codes and keywords for extending the macro language.

Further features and advantages of the present invention and the structure and operation of various embodiments of the present invention will be described with reference to the accompanying drawings.

Like reference symbols in the drawings indicate like or functionally similar elements.

The present invention relates to an extensible macro language that can be dynamically extended in a runtime environment without the need to rebuild and recompile the macro language. Although the extensible macro language includes a set of macro instructions, the present invention allows the user to add additional or new macro instructions as desired. 1 is a block diagram 100 illustrating components of a system for providing an extensible macro language of the present invention. Parser 102 includes grammar or syntax 104 that parses and parses certain expressions using the parser. As shown in FIG. 1, the parser 102 receives the macro language representation 106 and parses it into components according to the syntax 104 of the macro language. Hereinafter, the syntax used in the embodiment of the present invention will be described in more detail. In FIG. 1, the parser 102 reads a representation 106 that recognizes some predefined token in a syntax that indicates the presence of a new macro command. In this example, when parser 102 encounters a curly brace in expression 106, parser 102 may add a new macro command to a keyword, such as a "character" contained within the brace. Treat as. In addition, the parser 102 recognizes based on the syntax 104 that the "name" inserted in the insertion phrase is a parameter for the new macro instruction. Another form of syntax 104 may be to follow a string of characters outside any symbol to be interpreted as a literal string. Thus, parser 102 divides each element of the representation into components as shown by 108. A novel feature of the parser 102 in the present invention is that the parser 102 is independent of the actual content in the token, namely Curly Brace. That is, as long as a new macro command or keyword is inserted into a recognizable token, parser 102 splits it into components regardless of whether the keyword is predefined in a macro language. Thus, as shown at 108, the macro representation 106 is divided into components according to the syntax 104 of the extended macro language. The new keyword "attribute" is split as token component 108a, the string "name" in the insert is split as parameter component 108b, and the string "like" is split as literal component 108c and , The string "pizza" is split as a literal component 108d.

As shown in FIG. 1, the present invention also includes a macro handler 110, a repository 112 having keywords and executable code corresponding to the keywords. Executable code may be stored in storage 112 as a pointer to actual code for execution. Repository 112 includes one or more keywords and associated code, and can be dynamically modified, for example, new keywords and codes added to the repository are generated by users of the macro language as needed. Repository 112 of the present invention may be a simple file having a table of keywords and associated codes. Alternatively, a separate database can be used as the repository 112.

After the macro representation is parsed into separate components as described above with respect to parser 102, the components are passed to macro handler 110 for further processing. For token components with the keyword "attribute" 108a, the macro handler checks the repository for the keyword "attribute". Once the keyword property is found, the code associated with the keyword "attribute" is retrieved and executed. In executing the code, the macro handler 110 passes all the parameters found in the macro representation and parsed (parsed) as parameters into the executable code. The macro handler 110 does not need to know other processing that can be performed within the code itself. All that macro handler 110 needs to be aware of is the keyword whose "characteristic" is to be found in the repository 112 for its corresponding code, and the corresponding code defined in the repository 112 to be executed with some parameter. The corresponding code is typically defined in the storage 112 as a pointer to the actual code itself 114.

After proper execution of the defined code 114 in the repository, the macro handler 110 accepts one or more outputs of the executed code and places the output back in the macro representation instead of a keyword. As such, in the example shown in FIG. 1, the output of the code associated with the parameters "name" and "characteristic" may be Mary. Thus, the result of the expanded macro expression, such as "{character (s)} like pizza" at 106, is "Mary likes pizza", as shown at 116.

A new feature of the present invention is that a macro handler such as a parser does not need to know anything in the code, or need to know which function type is performed by the executable code. Macro handlers only provide an introduction to the executable code associated with a keyword. In the illustrative embodiment of the present invention, a flexible and extensible macro language is provided because it is up to the user to precisely define which code should be executed and therefore which commands are performed by keywords.

In this embodiment, the output MARY can be obtained in a variety of ways independent of the macro language. For example, the name Mary can be obtained from a database using a query language that describes the scalability that can be obtained by performing a search on the World Wide Web or is acceptable by the present invention.

Language syntax

The syntax or grammar used in one embodiment of the extensible macro language will be described in more detail. The extensible macro language of the present invention includes syntax (104 in FIG. 1) that includes literals, macros, comments, and operator / scoping characters.

Literal

In this embodiment, the syntax treats the mode text outside the Curly Brace as a literal and is generated by typing correctly. Within curly braces, text in double quotes is treated as a literal. This method makes it possible to insert literals within macro calls. Some examples of literals are:

This text is generated as follows:

{"So would this text"}

Macro

A macro contains instructions for a macro processor, such as a procedure or function, in a programming language. According to the syntax defined in the present invention, all macros are inserted into the curly brace. In one embodiment, macros fall into two categories: procedural macros and repeat macros.

Procedural macros are designed to do something. A procedural macro can expand to one value, a procedural macro can represent a variable, and a procedural macro can start a process. The action taken is defined entirely by the designer of the macro. However, in one embodiment, the macro returns a "true" value upon successful completion of the macro operation and a "false" value if the operation fails.

The following expression represents a string literal followed by a macro call to get the page number on printing.

My Model Report-Page {HeaderPage}: Input

My Model Report-Page 1: Output

In the above example, HeaderPage is a user defined macro to extract the page number.

Iterator macros allow users to traverse a data structure. Iterators are distinguished by the keywords "start" and "end", which separate the blocks of code that follow the iterator declaration. The code in the "start / end" block is executed once for each iteration. When an iterator moves across all objects in its pool, the control divides it into repeating blocks and continues executing the next statement with the macro representation following the block.

The next block of macro expressions indicates the use of iterator macros.

{

Myiterator

begin

DoSomething

end

}

In the example above, the procedure macro "DoSomething" executes once for each element returned by the "MyIterator" macro. Indicates that all expressions in Curly Brace enclosing the entire fragment are treated as macro code.

parameter

The syntax defined in the extensible macro language of the present invention allows procedures and iterators to accept and process parameters. The parameter may include a string or other macro. To distinguish between parameters, the parameters are nested within the insert following the macro. The macro can accept a variable length parameter list as desired. The following shows a macro representation with the parameter "foo".

{MacroWithParameter ("foo")}

Control block

In either case, it is desirable to have a macro representation block of failure if it fails to represent any part of the macro representation. The following example illustrates this case.

{FirstName [MiddleInitial "."] LastName}

If there is no middle initial, the MiddleInitial macro will return a nil value or a failure value. In that case, the literal "." Should not be printed. To use these conditions, the present invention includes a square bracket ("[]") that represents a conditional expression in its syntax. Therefore, if the macro in the square bracket fails, the remaining representation in the square bracket does not occur. In the above example, if MiddleInitial fails due to lack of value, the literal "." Is not printed.

Conditional blocks have internal scopes. In other words, the failure of a conditional block does not affect the surrounding code. In the case of a block condition affecting an outer block, the phrase additionally includes what is called a propagation condition labeled with an angle bracket. If any macro in a pair of angle brackets fails, the block in the angle bracket and the next outer block are broken. The following example shows a macro representation with conditional propagation conditions.

{Print "" [Print [Fail]]}: input

foo foo: output

{Print "" [Print 〈Fail〉]}: input

foo: output

In both examples, the "print" macro outputs the word "foo". In a first example, a macro that has failed in a square bracket is contained within its block. Therefore, the next outer block with "print" is executed as the first "print", resulting in the output "foo foo". In the second example, if the macro in the angle bracket fails, then the failure has the "print" macro. Propagated to the block. Therefore, the next outer block with "print" is not executed. Since this print macro is contained within a pair of square brackets, a failure is contained within the block. Therefore, the first "print" macro is executed and the output "foo" is output.

2 is an example of a macro representation comprising an iterator macro of the present invention. As described with reference to FIG. 1, the keyword "ForEach" is recognized as a macro by the parser 102 (FIG. 1) and the word "Employee" is recognized as a parameter for the macro "ForEach". When the macro handler receives the token keyword "ForEach", the macro handler 110 (FIG. 1) performs a lookup of the keyword "ForEach" in the registry 112 and executes the corresponding code. The code for the "ForEach" macro performs the instructions found in the start / end block of the macro representation for all sub-objects 204b, 204c of the given object 204 with the type of the defined parameter "employee". . In this macro representation 202, another macro is present in the start / end block. Thus, the macro handler 110 (FIG. 1) performs a lookup of the keyword "Property" in the registry 112 and corresponds to each of the sub-objects 204b and 204c having the employee type as defined by the "ForEach" keyword. Run the code The code associated with the "Property" keyword may include an instruction to print a value of the type specified in the parameter of the keyword "Property", an employee name as defined in this example as "EmpName". Thus, the result of the macro representation 202 is the output, "Mary John", shown at 208.

The extensible macro language of the present invention is useful for tailoring macros to the specific needs of individual users. For example, an extensible macro language is interfaced with the UMA model to retrieve various objects from the UMA model as desired by the user. The name of the invention, filed October 15, 1999, which is incorporated herein by reference, is disclosed in co-pending US patent application Ser. No. 60 / 104,682, which is an apparatus and method for modeling a tool. Appendix A contains a brief description of the extensible macro language of the present invention, used in the UMA model and referred to as the UMA template language. The description in Appendix A describes an embodiment of an extensible macro language and should not be construed as limiting the scope and capabilities of the extensible macro language to the description contained herein.

While the invention has been shown and described in connection with the embodiments, those skilled in the art will recognize that modifications and variations of the foregoing forms may be made without departing from the spirit and scope of the invention.

Appendix A

summary

The purpose of this document is to provide a brief introduction to the template language implemented in UMA. Readers of this document assume that they have a working knowledge of UMA's object / property metamodel.

This document should not be considered as providing an exclusive description of the architecture. UMA team members can provide this description to readers of this document, and can direct readers to many code samples that take advantage of this usefulness.

The purpose of the UMA Template Language (UTL) is to provide scripting capabilities for applications based on UMA. These functions are available for various features and include, but are not limited to, the following.

Macro extension : Extend the execution time of code templates for models. Examples include trigger code and stored procedures in OR Compass, Visual Basic and Java components in SQL Compass.

Scripting : Execution of a series of instructions to a model. One example is controller code for forward engineering in OR Compass.

UTL's architecture is intended to facilitate its use in various forms of products, possibly based on UMA. This is accomplished by revealing mechanisms that allow the user maximum flexibility in adapting the language to the specific needs of his product, provide as much implementation support as possible, and allow reuse of new implementation code.

To achieve this goal, UTL

1. Define the minimum syntax for the language,

2. enable the user to record procedures and iterators,

3. Provide a mechanism for registering procedures and iterators in the registry.

Syntax Summary

The following is an overview of the syntax of the UTL, which is intended to provide the minimum bareness needed to understand the implementation. More information can be found in the documentation moved to OR Compass 1.0.

Template code consists of literals, macros, and some operator / scoping characters. Currently, UTL observes all code as strings. In other words, numeric values are described as string representations, and most macros calculate strings and the like.

Literal

In the template source code, all textual exterior of the Curly Brace is treated as a literal and is generated exactly as typed. Within Curly Brace, the text in double quotes is treated as a literal. The former causes a large block of boilerplate to be input into the body of a stored procedure, for example. The latter makes it possible to embed literals in macro cells.

Yes:

This text will be issued like this.

{"So would this text."}

Macro

A macro is a macro processor, basically a specific instruction for a procedure. All macros are contained within the Curly Brace. Macros basically fall into two categories. That is, it belongs to procedural macros and iterator macros.

Procedural macros are designed to do something. Procedural macros can be expanded to any value. A procedural macro declares a variable and can start a process. The action taken is fully defined by the macro's designer. The only restriction on procedural macros is that the procedural macros return true and false for failures for successful completion of the procedural macro's work.

Example—The following shows a string literal following a macro call to get the page number on printing.

My Model Report-Page {HeaderPage} ← Input

My Model Report-Page 1 ← Output

Iterator macros allow users to traverse across data structures. An iterator is identified by the beginning and end of the keyword that separates the code block following the iterator declaration. All code in this start / end block will be executed once during each iteration. When an iterator moves across all objects in its pool, control divides the repeating block to execute the first statement following the block.

Example-The following executes the procedural macro DoSomething once for each element returned by the MyIterator macro. Note the color brace surrounding the entire code fragment, indicating that all code is treated as macro code.

{

Myiterator

begin

DoSomething

end

}

Procedures and iterator macros can take parameters. A parameter is something you compute on a string, such as a string or another macro. If the macro takes a parameter, the parameter is included in the insert after the macro. Since no forward declaration of the macro is required, the macro can accept a variable-length parameter list if desired.

Yes:

{MacroWithParameters ("foo")}

Control block

Sometimes it is desirable to have an entire block of template code failures if any portion of the template code fails. An example would be if there is some boilerplate text followed by a selection. If the value is not present, no boiler plate should be generated.

Cords embedded in square brackets are conditional. If any part of the code is broken, it is all broken. "Fault" means that the macro does not run and no literals are generated.

Yes-If there is no middle name, do not put a period.

{FirstName [MiddleInitial "."] LastName}

The conditional block hides its inner range. This means that the failure of the conditional block does not affect the surrounding code. The cords enclosed in the angle brackets are propagated. If any part of the code fails, the code is broken and the code will propagate the failure from the next block.

The best way to distinguish these two types of blocks is as follows: In both examples, the print macro generates the word "foo" and the fault macro fails anyway.

Example of conditional block

{Print "" [Print [Fail]]} ← Input

foo foo ← Output

Example of Propagation Conditional Block

{Print "" [Print 〈Fail 〈]} ← Input

foo foo ← Output

Architecture

LWMDataButler

The desired functionality of the UTL is accomplished using an object called a data butler. Data Butler is responsible for providing an implementation for the macros encountered by the macro processor when executing the template code. When the macro processor is started, the data butler interface is provided to the macro processor. Essentially, the data butler uses a strategy pattern.

This achieves the first goal of language design. By providing different data butlers to the macro processor, the grammar of the UTL can be configured for future applications and tasks. The data butler implementation may accept a set of keywords (macro) appropriate for the task and reject the unacceptable keywords. In addition, certain keywords may be implemented in different ways by different data Butlers, allowing the template code to ignore the underlying implementation. This is useful for making it possible to work with multiple products from the same template when the underlying data models are different.

MCDataButlerl

The second design goal of the UTL is to give the user as much functionality as possible so that he can publish his code for reuse.

Since the metaphor of the UMA model covers all data at a very abstract level, many grammatical elements of objects and properties, i.e., template language, can be recorded abstractly. These elements can be brought together to form a major part of the language needed by products based on UMA. The user should extend this base in several areas of specific products. Ideally, the language should be extended not only by the user but also by the end user of the user's product. This is achieved in our solution.

There are two basic problems solved by the solution.

A mechanism is needed to share the implementation. When a new keyword is added, a new keyword must be published.

2. A mechanism is needed to control the execution context of the macro. This refers to specific objects or properties that the macro and state of the UMA model affect at run time.

To meet these criteria, UMA has a basic implementation of data butler. This implementation, MCDataButler ⁵ , provides a mechanism for progressively defining the desired grammar and managing contextual information in the UMA model.

This implementation is a superset of the LWMDataButler interface. Although the LWMDataButler interface is exposed, the user does not need to associate himself with the interface when implementing the data butler. The implementation in MCDataButlerI achieves everything that needs to be done considering the implementation of the LWMDataButler interface.

First, LWMDataButlerI manages the macro handler's registry. Macro handlers are objects that know how to perform an action, given a context. Conceptually, a macro handler is an example of a command pattern. Data Butler is a dictionary of macro handlers keyed by macro name. When the macro processor requests a data butler to handle a macro (eg, via value () substitution), the data butler places the appropriate macro handler in its dictionary and delegates control to the dictionary. The macro handler processes the request and returns control (if any) and success status to the data butler, which simply proceeds to the macro processor.

The macro handler exposes the interface that the data butler uses for ordering.

LWMDataButlerI exposes the implementation signature to register a new handler.

To implement the grammar, you can configure the implementation of LWMDataButlerI and implement all the necessary macro handlers. Alternatively, because the macro handler registry is a member of the data butler instead of a singleton, the user can subclass an existing data butler. This gives the user the development of all the macro plus users known to the subclass. An example of this is OR Compass Forward Engineering Data Butler, which subclasses MCDataButler. The latter implements a wide variety of general macros for creating objects, reading properties, iterating, and constructing variables. The forward engineering data butler implements one or more macros (such as macros that determine the correct execution instructions for a database) that are related to forward engineering and ends with a complete syntax for issuing DDL.

Second, LWMDataButlerI manages the context stack. The context stack lets the macro handler know which object in the UMA model it refers to when the macro runs. For example, the property macro retrieves a named property from an object. The macro handler for the property () needs to know which object to query.

LWMDataButlerI exposes an interface for holding a stack of object references, pushing and popping objects to this stack, and querying the stack. The macro handler can query the interface to find the context of the operation.

In addition, LWMDataButlerI exposes the ability to allow MCObject iterators to automatically manage context. Macro handlers for iterator macros can illustrate an iterator proxy. This is the object that automatically maintains the context stack for the iterator. When instantiated, it pushes the first object repeated in the context stack. If there are no more items to traverse, the stack is popped, leaving it as it existed when the iterator was encountered. This iterator proxy is kept on its own stack to manage nested iterators.

Example- Here is sample code that shows how a property macro behaves differently depending on the context. Consider the entity named "MyTable" with the attribute "MyColumn1" and the second attribute "MyColum2". Consider a second entity named "MyTable2" with the attribute "MyColumn3". This template code executes and assumes that the current stack has a model on top of which it should be given to some other code.

MyTable1 MyColumn1 MyColumn2 MyTable2 MyColumn3 ← Output

Claims (5)

As a way to provide an extensible macro language, Analyzing the macro language expression, Determining one or more keywords in the analyzed macro language representation based on a predetermined syntax of the macro language, the macro command representing a macro command not predefined in the macro language; Retrieving the code associated with the keyword from the registry of keywords; Executing code associated with the keyword. 2. The method of claim 1, further comprising extending a registry of keywords by inserting new keywords and code associated with the new keywords. As a system for providing an extensible macro language, A parser embedded within a macro language representation, the parser having a predetermined syntax for determining one or more extended keywords that are indicative of a macro command that is not defined by a predetermined set of macro commands in the macro language; A keyword store with one or more keywords and associated codes, A macro handler coupled to the parser for receiving an extended keyword from the parser, the macro hander retrieving code associated with the extended keyword received from the keyword store in response to the received extended keyword; An extensible macro language-providing system that executes code for executing macro commands expressed in. 4. The system of claim 3, wherein the keyword repository is increased to include new keywords and associated code. As a way to parse macro language expressions, Analyzing macro language expressions, Determining one or more keywords in the analyzed macro language representation based on a predetermined syntax of a macro language, wherein the keywords represent macro commands that are not defined by a predetermined set of macro commands in the macro language. Method for parsing an expression.