CN111930374A

CN111930374A - Data formatting method, data formatting device, programming system, data formatting equipment and storage medium

Info

Publication number: CN111930374A
Application number: CN202010997873.XA
Authority: CN
Inventors: 陈刚; 林锋; 王苗苗
Original assignee: Beijing Yizhen Xuesi Education Technology Co Ltd
Current assignee: Beijing Yizhen Xuesi Education Technology Co Ltd
Priority date: 2020-09-21
Filing date: 2020-09-21
Publication date: 2020-11-13
Anticipated expiration: 2040-09-21
Also published as: CN111930374B

Abstract

The data formatting method, the data formatting device, the programming system, the equipment and the storage medium of the application comprise the following steps: acquiring a graph code component combination; and representing each graphic code component contained in the graphic code component combination as formatted data on a plurality of data dimensions to form the formatted data of the graphic code component combination. The scheme of the application generates formatted data by considering the formatting mode of the context of the graphic code component, so that the situation that the linked list data format and the building block format of the original code in the existing graphic programming education software are different is changed, and the difficulty of code analysis is reduced; in addition, a more flexible work checking mechanism may be implemented by formatting the data.

Description

Data formatting method, data formatting device, programming system, data formatting equipment and storage medium

Technical Field

The embodiment of the application relates to the technical field of programming teaching, in particular to a data formatting method, a data formatting device, a programming system, a data formatting device and a storage medium.

Background

Based on the current need for logical thinking training in education, various logical thinking-like electronic teaching tools continue to emerge. Especially in the case of the high dependence of today's society on computer network technology, programming teaching courses are also facing users of an ever-decreasing age.

For this reason, some more intuitive and interesting graphic programming teaching software has appeared, such as simple graphic programming tool (Scratch) of massachusetts institute of technology, etc., which provides a programming way of "building blocks", i.e., a user can combine the graphical code blocks through operations such as clicking and dragging, etc., to complete the programmed works.

Scratch has evolved to version 3.0. However, the user interface of Scratch 3.0 has a definite functional partition, and the user code is clear because of the building block programming mode. However, the source code of the Scratch 3.0 data layer is stored in a JSON data format, in the JSON file, each building block in the role script region is assigned with a random unique building block identifier (key), and the building blocks are connected with one another in a linked list manner, so that the code is more complex after nesting is generated, the source code of the work is difficult to read, and secondary development cannot be directly performed. In addition, when the Scratch work runs, each block is analyzed independently, and the data formats of different blocks have large differences.

In summary, under the dual influence of the linked list data format and the building block format heterogeneity adopted by the Scratch, it is very difficult to directly perform plaintext parsing on the work source code of the Scratch.

Disclosure of Invention

In view of this, embodiments of the present application provide a data formatting method, an apparatus, a programming system, a device, and a storage medium, which solve the technical problems in the prior art.

The embodiment of the application provides a data formatting method, which is used for formatting a graphic code component combination consisting of graphic code components; the data formatting method comprises the following steps:

acquiring a graph code component combination;

and representing each graphic code component contained in the graphic code component combination as formatted data on a plurality of data dimensions to form the formatted data of the graphic code component combination.

Optionally, the plurality of data dimensions include: executing roles, events, sequential logic, and types; in the case of a graphical code component having parameters, the plurality of data dimensions further includes parameters.

Optionally, the formatting method includes:

acquiring execution role information of each graph code component in the graph code component combination; the graphic code components are grouped according to respective execution roles to form execution role groups;

acquiring event information related to each graph code component under the execution role group to which the graph code component belongs; the graphic code components under each execution role group are grouped according to the respective related event information to form each event group;

extracting the type of each graph code component under the event group, depth information representing the nesting relation of the graph code components and parameters of the graph code components with the parameters according to the arrangement sequence;

and forming the formatted data of each graphic code component according to the extracted information of each graphic code component, and forming the formatted data of the corresponding graphic code component combination according to the arrangement sequence.

Optionally, the extracting, according to the ranking order, the type of each graph code component in the event group, the depth information indicating the nesting relationship of the graph code components, and the parameter of the graph code component having the parameter includes:

accessing each graphical code component one by one;

adding the graphic code component which is judged to need recursive processing into a first recursive queue;

extracting information from each graphical code component outside the first recursion queue and incorporating the corresponding formatted data;

information is extracted from each graphical code component in the first recursion queue and placed into corresponding formatted data.

Optionally, the extracting information from each graphics code component outside the first recursion queue includes:

screening the effective parameters of each graph code component one by one;

and placing the graphics code components which need to be subjected to recursive processing into a second recursive queue.

Optionally, the second recursive queue recursively processes with a higher priority than the first recursive queue.

Optionally, the graphics code component requiring recursive processing includes at least one of: graph code components in a nested relationship; there are graphical code components of optional parameters.

The embodiment of the application also provides a data formatting device, which is used for formatting the graphic code component combination consisting of the graphic code components; the data formatting device includes:

the acquisition module is used for acquiring a graphic code component combination;

and the formatting unit is used for representing each graphic code component contained in the graphic code component combination into formatted data on a plurality of data dimensions so as to form the formatted data of the graphic code component combination.

An embodiment of the present application further provides a graphic programming system, including:

the graphical programming unit is used for providing a graphical programming interface for a user, and is used for receiving user operation and combining the operated graphical code components into a graphical programming product;

and the formatting unit is realized by the data formatting device and is used for formatting the graphic programming product or the related graphic code component combination thereof to obtain corresponding formatted data.

The embodiment of the present application further provides a computer device, which includes a memory and a processor, where the memory stores a computer program executable on the processor, and the processor executes the steps of any one of the data formatting methods when executing the computer program.

The embodiments of the present application further provide a computer-readable storage medium, on which a computer program is stored, where the computer program executes the steps of any one of the data formatting methods.

Compared with the prior art, the technical scheme of the embodiment of the application has the following beneficial effects:

in the embodiment of the application, formatted data is generated by considering the formatting mode of the context of the graphic code component, so that the condition that the linked list data format and the building block format of the original code in the existing graphic programming education software are different is changed, and the difficulty of code analysis is reduced; in addition, a more flexible work checking mechanism may be implemented by formatting the data.

Drawings

Fig. 1 is a graphical user interface diagram of Scratch.

Fig. 2 is a schematic diagram of a combination of blocks in Scratch.

Fig. 3 is a schematic flow chart of a data formatting method in an embodiment of the present application.

Fig. 4 is a flowchart illustrating a method for performing data formatting on a specific data dimension according to an embodiment of the present application.

Fig. 5 is a schematic diagram of the principle of formatting data in the embodiment of the present application.

Fig. 6 is a flowchart illustrating a method for performing data formatting using a recursive queue according to an embodiment of the present application.

Fig. 7 is a flowchart of the formatting of the actual code corresponding to fig. 6 in the embodiment of the present application.

Fig. 8 is a flowchart illustrating an implementation of S708 in fig. 7.

Fig. 9 is a schematic structural diagram of a data formatting device in an embodiment of the present application.

Fig. 10 is a schematic structural diagram of a formatting module in the data formatting apparatus according to the embodiment of the present application.

FIG. 11 is a schematic structural diagram of a graphic programming system according to an embodiment of the present application.

Fig. 12 is a schematic structural diagram of a computer device in an embodiment of the present application.

Detailed Description

Graphic programming teaching software has been applied to programming teaching for children and teenagers. Such as the scission, a simple graphical programming tool of the institute of technology, ma, the user may manipulate various "programming bricks" in the graphical user interface of the scitch and combine to form a graphical programming work.

As shown in fig. 1, a graphical user interface diagram of Scratch is presented.

In the graphical user interface diagram of Scratch shown in fig. 1, a left column 101 shows code blocks that can be selectively used, such as code blocks of various types, such as "motion", "appearance", "sound", "event", "control", and the like, and code blocks with various relevant appearances shown by selecting an "appearance" option are shown in the diagram; the programming area 102 in the middle of the diagram shows a graphical programming work formed by combining selected code blocks, and illustratively shows that "when a flag (graphically represented in the figure) is clicked", the execution character "moves 100 steps" to "bounces when hitting an edge", the rotation mode of the execution character is set to "flip left and right" (the inverted triangle in the figure represents a drop-down list, and an action can be selected by operating on the drop-down list), and the execution character "turn right 15 degrees" says "hello! Playing sound meow and showing the next model; the right column in the figure shows the executing character area 103 at the lower right and the animation showing area (generally called "stage area") 104 above the executing character area, wherein the animation result correspondingly presented after the code of the graphic programming work is executed can be shown, and the executing character can be a cartoon cat "can many" corresponding to the sound of "meow" described above. Of course, the execution roles may be multiple, for example, the execution role area 104 on the right side may be separately displayed, for example, the execution roles have a cat and a dog, the user may select the corresponding execution role, and the programming area 102 in the middle may program the code blocks corresponding to the selected execution role, in which the character "cat" has a different texture from "dog" to indicate that it is selected.

In Scratch, there are various types of building blocks, and their forms are different. Most of the program programs start with an event block, for example, the uppermost code block "when the flag is clicked" shown in fig. 1 is the event block.

In some examples, a "graphical code component" as referred to herein may be a code block in Scratch, a combination of graphical code components may be a combination of blocks resulting from building blocks in Scratch, and a graphical programming product may be a product formed from one or more combinations of blocks, such as the content illustrated in fig. 1. It should be noted that the graphic programming product of a block set shown in fig. 1 is only an example, and actually, the graphic programming product is not limited to the number of block sets, for example, there are one or more execution roles (e.g., cat, dog, etc.), each of which can execute one or more events, and then one or more event-related block sets are correspondingly formed, and each block set starts with an event block.

In fig. 2, a building block combination is shown, functioning as follows: when the flag is clicked, the character will move forward 10 steps, and if the character enters the area after 10 steps, the character will say "hello".

In Scratch 3.0, the whole source code is stored in JSON data format, which is a lightweight data exchange format.

Illustratively, the JSON code corresponding to the building block combination of fig. 2 is as follows code segment 1:

{

"building block 1": pen-eye

"opcode", "event _ wbenflagclicked",// event

Next is building block 2, and/the next is building block 2"

Parent,// there is no parent building Block

"inputs":{

},

"fields":{

}

},

"building block 2": pen-eye

"opcode", "motion _ movesteps",// move action

Next building block 3, and/Next building block 3"

"parent" block 1", and/parent block 1"

"inputs":{

"STEPS" [1, [4, "10" ]// the number of moving STEPS is "10"

},

"fields":{

}

},

"building block 3": pen

"opcode": control _ if,// if

"next":null,

"parent" means "building block 2",

"inputs":{

"CONDITION": 2, "Block 4" ],// Condition: if "building block 4"

"SUBSTACK": 2, "Block 5" ]// branch: then "building blocks 5"

},

"fields":{

}

},

"building block 4": pen

"opcode" "sensing _ touching color",// touching color

"next":null,

"parent" means "building block 3",

"inputs":{

"COLOR" [1, [ 9, "# a3cc33" ]// COLOR, "# a3cc33"

},

"fields":{

}

},

"building block 5": pen-eye

"opcode": looks _ say,// appearance: 'say'

"next":null,

"parent" means "building block 3",

"inputs":{

"MESSAGE" [1, [ 10, "hello! "]// say: "hello"

},

"fields":{

}

Each code building block is assigned with a random unique building block identifier (called key), for clear view, the building block identifiers are represented by ' building blocks 1 ' -5 ' and the like in the codes in an alternative manner, and if in actual implementation, the building block identifiers can be a random character string consisting of a string of letters, numbers and symbols; it can be seen that in the data structure corresponding to each current code building block, the next building block adjacent to the current building block is marked by the key in the next field, and the previous building block of the current building block is marked by the key in the parent field, so as to determine the sequence of the building blocks; if the value of the previous block "parent" is "null", i.e. "empty", this means that this block is the first block in the combination, which may be for example an event block.

It can be seen that the "opcode" field is the name of the block (i.e., the "type" of the block), and parent records the block identification of the last block. The parameters of the blocks are dispersed in the "inputs" and "fields, for example, the" hit COLOR "block is named COLOR for the parameter and STEPS for the" move "block.

In addition to their sequential relationship to each other, the above-described block combinations also have more complex "nesting" relationships, such as "if … then" there are two nesting relationships in the block: "hit color" is a "if …" conditional block, say "is a block to be executed when the condition is met. In the original JSON file, the block with "opcode" as "container _ if" represents the "if …" block of the user interface, two random block identifiers appear in the array corresponding to "CONDITION" and "SUBSTACK" in the "inputs" field of the block, and the blocks with "opcode" as "sensing _ touching color" and "hooks _ say" are found in the code through the two block identifiers, namely the "touching color" and "saying" block on the user interface, which means that the two blocks are nested in "if …" block.

Comparing the descriptions of the parameters in the two sections, it can be seen that in the original JSON of the building block, the nesting relationship is very similar to the parameters in the code format, which is easy to be confused, and is not beneficial to the plaintext analysis of the code.

In an embodiment of the present application, a scheme for formatting a graphical code component combination (e.g., a building block combination) may be provided.

Fig. 3 is a schematic flow chart illustrating a data formatting method according to an embodiment of the present application. The data formatting method is used for formatting a graphic code component combination consisting of graphic code components; the data formatting method comprises the following steps:

step S301: a graphical code component combination is obtained.

Step S302: and representing each graphic code component contained in the graphic code component combination as formatted data on a plurality of data dimensions to form the formatted data of the graphic code component combination.

In some examples, the formatting refers to representing each block comprised by a block combination as formatted data in multiple data dimensions. In an example of a particular implementation, the plurality of data dimensions includes: executing roles, events, sequential logic and types; wherein, in the case of a building block having a parameter, the plurality of data dimensions further comprises the parameter.

The execution roles are, for example, "may be" of cat in fig. 1 or other execution roles in the execution role library, and all the building block combinations in the embodiment of fig. 1 may be the execution roles "may be" of cat.

For another example, in the block combination in the embodiment of fig. 1, it can be seen that the first block is an event block, and the subsequent code blocks all belong to the event block, so that the event to which the subsequent code block belongs can be determined by the event block, and the block combination to which the code block belongs can be uniquely determined by determining the information of the event to which the code block belongs.

As another example, the name "opcode" of a code block represents its name (i.e., type), e.g., "motion _ movesteps" represents a move.

The sequential logic includes the order and nesting relationship of the code blocks.

The sequential relationship refers to an arrangement sequence of the code blocks in the block combination, for example, an arrangement sequence of the code blocks from top to bottom in fig. 2, and the arrangement sequence also corresponds to the code sequence of the block combination, for example, as shown in the foregoing code segment 1.

Regarding the nesting relationship, for example, the "if.

Optionally, the nesting position of each block can be represented by the depth information of each block, and from the outer layer to the inner layer of the nesting, the value of the depth information of each block can be represented by adding 1 to each deep layer of the nesting. For example, it is assumed that each code block without a nesting relationship is represented by a depth information value of "1", for example, in fig. 2, the depth information values of "when the flag is clicked" and "moved" are "1"; the values of the 'touch color' and 'say' depth information of the nested building blocks can be set to be '2' one level deeper than '1', and if the 'touch color' is changed into other nested building blocks, the values of the depth information of the nested building blocks can be '3' one level deeper.

For another example, some of the blocks illustrated in fig. 2 have no parameters, for example, if the flag is clicked, the block has no parameters, and the "move" block has parameters, which can be included in the formatted data of the corresponding block.

In Scratch, a user assembles code blocks in an execution role area opened by a corresponding execution role, so that the corresponding code blocks can be under the execution role, the blocks combined by the blocks are generally event blocks which represent one event under the execution role and are other blocks downward, and nesting relations may exist among the graphic code blocks, wherein some are parameter blocks and some are non-parameter blocks.

In some examples, corresponding to the above-mentioned upper and lower level relationships, a method corresponding to the flow diagram formatted as shown in fig. 4 may be performed, which specifically includes:

step S401: acquiring execution role information of each graphic code component; and the graphic code components are grouped according to respective execution roles to form execution role groups.

For example, if a graphical programming product includes a first combination of graphical code elements having a kitten 'many' execution role, each graphical code element in the first combination of graphical code elements will be assigned to the kitten 'many' execution role group; similarly, if the graphic programming product further includes a second graphic code component combination using the puppy as the execution role, each graphic code component is classified into the execution role group of the puppy.

Step S402: acquiring event information related to each graph code component under the execution role group to which the graph code component belongs; and the graphic code components under each execution role group are grouped according to the respective related event information to form each event group.

For example, the execution role of the combination of graphic code components in fig. 2 is "many cat", and then it is attributed to the "many cat" execution role group, further, the first graphic code component of the combination of graphic code components is of event type, "when the flag is clicked", it is taken as an event to form an event group, and the subsequent graphic code components are all attributed to this event group.

Step S403: the type of each graphic code component under the event group, the depth information indicating the nesting relationship thereof, and the parameter of the graphic code component having the parameter are extracted in the ranking order.

The arrangement sequence is the sequence of each graph code component in the graph code component combination.

As described in the previous embodiment, the type is represented by a name extracted from "opcode"; the nesting relationship is represented by depth information, for example, the value of the depth information such as "when the flag is clicked", "moved", "if.. then" may be set to "1", and the value of the depth information such as "hit color" and "say" of "nested block nesting may be" 2 "; the parameter is, for example, a parameter "10" in "move" in fig. 2, a color code "# a3cc33" in "hit color", or the like.

Step S404: and forming the formatted data of each graphic code component according to the extracted information of each graphic code component, and forming the formatted data of the corresponding graphic code component combination according to the arrangement sequence.

The graphical code component assembly of fig. 2 corresponds to the previous code segment 1, and after formatting, the formatted data of each graphical code component in the resulting graphical code component assembly is represented as [ name, [ parameter list ], depth information ], and the formatted data of the graphical code component assembly, which is integrated with the formatted data, can be represented in array form. For example, code segment 1 may be formatted as the following code segment 2:

{

"event_whenflagclicked":

[

["event_whenflagclicked", 1],

["motion_movesteps",["10"], 1],

["control_if", 1],

["sensing_touchingcolor", ["#a3cc33"], 2],

[ "looks _ say", [ "hello!" ], 2]

]

}

The meaning of the formatted data of each block in the above-mentioned code segment 2 is explained in detail.

For example, "event _ while flag" indicates that the event block of this set of block combinations is "when the flag is clicked". Each element in the array exposed below "event _ while marked" is the formatted data for one block.

The format data of the building blocks are in the forms of [ names, [ parameter lists ] and depth information ], the names correspond to opcodes of the building blocks, the parameter lists contain various parameters of the building blocks, and the depth information is used for representing the nesting relation of the building blocks.

In the example of the code segment 2, the arrangement order of the formatted data of each graphic coding element (i.e. building block) is identical to the arrangement order of the corresponding graphic coding element in fig. 2, i.e. the information of the arrangement order of the graphic code elements in the graphic code element combination is also restored in the corresponding formatted data.

It is understood that, in the arrangement order, a change of the nesting relation, such as occurrence or exit of a nesting relation, may be obtained according to a change of the depth information. For example, the depth information of the outermost graph code component is "1", the depth increases by "1" after the nesting relation occurs, the nesting depth increases by "1" for each deep layer, and the depth decreases by "1" for each layer of denesting release according to the arrangement sequence of the graph code components in the graph code component combination; if the depth information is reduced to be 1, the nesting relation of the outermost layer is indicated to be quitted; for example, from "if.. then" to "hit color" and "say," the depth information changes from "1" to "2," indicating that the nesting of "if.. then" is exited if the depth information of a subsequent graphical code component in the graphical code component combination appears to be "1. Similarly, if the depth information of the graphic code components in the combination is increased later, a new nesting relationship appears.

More specifically, the first element in the array is the formatted data of the formatted event block, which in this example is "when the flag is clicked," no parameter, and a depth of 1.

The second element in the array corresponds to the formatted data for the "mobile" block, which has a parameter of 10 and is in a mosaic relationship with the event block, so that the depth information is also 1.

The third element in the array is the formatted data for the "if … then" block, which contains nested blocks without its own parameters, keeping the succinctness of the "if …" block format since the nested relationships are only expressed by neighbor + depth information. The depth information of the third element is 1, which indicates that the third element is still in a splicing relationship with the second building block.

The fourth element in the array is the formatted data for the "hit color" block, which contains a parameter "a 3cc33," which is the RGB format color. The block depth information is 2 and the next previous block depth information is 1, indicating that the "color hit" block is a "if …" then "nested block of blocks.

The fifth element in the array is the formatted data for the "say" block, which contains a parameter "hello! "depth is 2, indicating that both the" say "and" hit color "bricks are" if … then "bricks in the nest of bricks. If there are other blocks in the end, if the depth becomes 3, it indicates that the nesting of the further level is entered, if the depth becomes 1, it indicates that the nesting of the block "if …" is ended, and it returns to the same depth as the block "if …".

To more intuitively explain the principle of the method of fig. 4, reference may be made to fig. 5, in which the right side shows an execution character group "kitten" (e.g., "kitten many"), "puppy", "kitten" having an event group "when the flag is clicked" under the execution character group, and an event group having formatting data of respective graphic code components, such as "when the flag is clicked", "moved", "if.

Shown on the left side of fig. 5 is a more specific data structure diagram of the formatted data of the graphic code components "when the flag is clicked" and "moved". The graphical code component "when flag is clicked" is parameter-free, which contains the operation code "event _ while clicked" (i.e., "event _ when flag is clicked") and depth information "1"; the "move" is parameterized and includes an operation code "motion _ moves" (i.e., "action _ move _ step"), a parameter (move step number "10"), and depth information "1".

As shown in fig. 6, a practical processing flow of the step S403 in a possible implementation is shown, which includes:

step S601: accessing each graphical code component one by one;

step S602: adding the graphic code component which is judged to need recursive processing into a first recursive queue;

step S603: extracting information from each graphical code component outside the first recursion queue and incorporating the corresponding formatted data;

step S604: information is extracted from each graphical code component in the first recursion queue and placed into corresponding formatted data.

In some examples, the graphics code components that require recursive processing may include at least one of: graph code components in a nested relationship; there are graphical code components of optional parameters.

For example, a building block with a nested relationship such as the "if. There are optional parameters of the graphical code components, for example a drop down list block, such as the "set rotation to" block in fig. 1.

The following shows a flowchart of an actual implementation of the above processing procedure in the embodiment of fig. 7, in combination with the JSON code of the existing Scratch, i.e. code segment 1, and the code segment 2 of the formatted data after conversion.

In Scratch, the first building block of an effective building block combination must be an event building block, so an event building block 'event' in a linked list is found as a starting building block, and each current building block is processed according to sequential formatting; after each current building block is processed, reading a next building block pointed by next in the current building block and continuing formatting processing; once a block needing recursive processing is encountered, recursive tasks are generated and inserted into a 'recursive queue', for example, a first recursive queue, namely recursive queue 1, and a second recursive queue, namely recursive queue 2, in the following flow are processed before a next block pointed to by next is processed; if the tasks exist in the recursion queue, the tasks in the recursion queue can be processed preferentially, a new flow can be started when the recursion is processed, and the depth information in the whole processing process can be + 1.

Taking the example of formatting the code of Scratch, in fig. 7, a flow of formatting the actual code is shown, which specifically includes:

step S701: and starting the steps.

Step S702: inputs are formatted for the first time.

For example, whether the current building block contains a building block identifier (key) which needs to be returned to the recursion queue is judged, and if yes, the current building block is added to the recursion queue 1; for a block with a pull-down list contained in Scratch, the block of the pull-down list may be formed by splicing a plurality of blocks, and the plurality of blocks may be processed by splicing in step S702. For example, the "sound playing" block in fig. 1 and "meow" therein are selected by the drop-down list, and it looks like "meow" is a parameter of the "sound playing" block, but actually "meow" may be a parameter in another block other than the "sound playing" block, and therefore, the two blocks may be spliced into one block in step S702.

Step S703: fields formatting.

For example, both fields of inputs and fields in Scratch may carry data, for example, when two blocks with a drop list are spliced into one block in S702, parameters selected by the drop list may be stored in fields spliced into one block; for uniform processing, fields may be merged into inputs in S703, i.e., parameters are merged into inputs.

Step S704: inputs are formatted a second time.

After fields are combined, inputs are formatted a second time, primarily for special handling of the parameters of the event blocks and "custom blocks".

Step S705: judging whether inputs are empty or not; if not, go to step S706; if yes, go to step S708;

and step S706, generating formatted data of the building blocks without the parameters.

If the inputs list is determined to be empty through S705, the building block is indicated to have no parameter, and formatted data of the building block without the parameter is generated according to the format and added into the array of the formatted result.

S707 and S712 process recursive queue 1: recursion queue 1 is a globally shared queue, that is, recursion queue 1 may already contain tasks to be processed when the current building block is parsed. In S702, if the inputs is found to contain a block requiring recursive processing, the block key and depth to be processed are combined into a "recursive task" to be added to the end of the recursive queue 1. The advantage of using "queue + recursion" is that the nested and nested blocks are adjacent in the final output array, preserving context, while the nested hierarchical relationship can be inferred from depth information.

Recursion queue 1 is primarily intended to handle known recursive blocks, often very conspicuous, such as "repeat execution" and "if. For example, when looking at the field "SUBSTACK" when traversing the input list of a repeatedly executed block, the internal value must be the key of the nested block, and "if. However, although the nested building block is found early, the parameters of the current building block may not be processed yet, so that the key in the SUBSTACK needs to be added to the recursion queue 1 in advance, and after the current building block is completely processed, the recursion queue 1 is checked to see whether there is a building block that needs to be processed.

S708, inputs are formatted for the third time.

The main purpose of this step is to screen each group of data in the inputs of each block and add the data to the parameter list, and if a block including the data to be recursively processed is encountered in this process, add the block to the second recursive queue, i.e. recursive queue 2; the recursive queue 2 to be screened out is used for collecting the blocks which are not particularly obvious and need recursive processing, and other blocks are usually put in the blocks, for example, the '10' parameter in the '10-step-moving' block is replaced by other blocks, for example, the 'loudness' and the like; optionally, the recursive queue 2 has a higher priority than the recursive queue 1, that is, when processing the recursive queue, the blocks in the recursive queue 2 are processed first, and then the blocks in the recursive queue 1 are processed.

In some embodiments, in step S708, the valid parameters of each graphics code component may be filtered one by one, and the graphics code components that are determined to need recursive processing may be placed in the second recursive queue.

As shown in fig. 8, a flowchart of the processing of S708 in the embodiment is shown.

Step S801: starting;

step S802: sorting the inputs in the inputs and traversing one by one;

in an implementation, the inputs are ordered because: building blocks containing multiple groups of parameters in Scratch sometimes, the sequence of the identification keys in the parameters is not fixed; from the two blocks connected and, the result of any one of these two blocks performed first will be different, so a sort is determined and processing continues. It is necessary to order the individual inputs therein.

In the process of traversing each input:

step S803: judging whether the input length is 3; if not, the step S804 is entered; if yes, entering S805;

in a specific implementation, input is the value corresponding to each field in the inputs. Since some blocks may be nested with other blocks, for example, the "move 10 STEPS" block 10 step position is a circular box, which is called a number box in Scratch, and besides the placement parameter, other circular blocks may be placed, for example, the "loudness" block is inserted into the "move 10 STEPS" 10 STEPS position, which causes the "move 10 STEPS" block inputs to change, the "loudness" block key is inserted into the STEPS field in the "move 10 STEPS" inputs, in which case the corresponding data length becomes 3.

Specifically, the input of "move 10 STEPS" corresponds to "STEPS": 1, [4, [ 10"], and assuming that the key of the loudness block is" abc ", the input of" move "loudness" STEPS "corresponds to" STEPS ": 3," abc ", [4, [ 10" ], and it can be seen that the data length in [ ] becomes 3, and thus special judgment is required.

Step S804: null values in input are removed and the last element last of input is marked.

Step S806: judging whether last is a character; if yes, the method proceeds to S807, if the parameter may be in the form of key or character; if not, the step S808 is entered;

step S807: judging whether last is the mark (key) of a certain building block; if yes, it indicates that last requires recursive processing (nesting is possible), then go to S809; if not, the step is S810 if it is indicated that last is only a common parameter;

step S809: adding the building blocks corresponding to the identifications to a recursion queue 2; then, the process goes to S811;

in a specific implementation, the last element of the input is chosen because the parameters that need to be extracted are typically at the end of the input, e.g., "# a3cc33" in COLOR ": 1, [ 9," # a3cc33 "]"; for another example, in a block of the drop-down list, for example, "touch" a mouse pointer "is a parameter of the drop-down selection, where the" touch "block related to the splice and other blocks storing the" mouse pointer "parameter," touch "the last element of input in the block is the key of this other block, the recursive processing in the recursive queue can jump to this other block, and the" mouse pointer "parameter is stored in fields of this other block, in the JSON code, the parameter of the" mouse pointer "is represented as" _ mouse _ ", and the corresponding field is represented as: "TOUCHINGOBJECTMENU"; the "mouse pointer" parameter can be extracted from this other block by extracting the input end element from inputs after they have been merged or directly from fields before merging.

Step S811: inputs traversal is finished or not; if yes, ending; if not, go back to step S802;

step S810: splicing last into a parameter list; then, the process goes to S811;

step S808: identifying whether the broadcast is broadcast; if yes, go to S812; if not, the process proceeds to S813:

the broadcast is a special building block in Scratch, such as a "broadcast message" building block, which has a structure different from other building blocks and therefore needs special processing.

Step S812: adding last [1] of the first element of last to a parameter list, namely, parameters of the broadcast type building blocks; then, the process goes to S811;

step S813: adding the last element of last to the parameter list; then, the process goes to S811;

step S805: whether the first element input [1] of input is a key of other blocks; if yes, input with key may be related to recursion, which means that the original variable is put into the digital frame, then S814 is entered; if not, the process goes to S815;

step S814: input [1] is added to recursion queue 2; then, the process goes to step S811;

step S815: whether input [1] is an array; if yes, go to step S816; if not, the process proceeds to S804, and the parameters are identified.

Step S816: indicates that a custom variable (located in an array) is placed in the number box and input [1] is added to recursion queue 2.

In some cases, input [1] and last [1] may be the same, e.g., "STEPS": 1, [4, "10" ], where 1, 4 are both internal values in Scratch, and may be omitted, and in "STEPS" [ "10" ], last [1] and input [1] get a parameter of "10", if the data length of input obtained as in the aforementioned S803 is 3, e.g., "STEPS": 3, "abc", [4, "10" ], then last [1] and input [2] are both "10", and "abc" may indicate the key of the other blocks placed in the mobile block.

Returning to the flow of fig. 7, after S708, the method further includes:

step S709, generating formatted data of the current building block containing the parameters: after S708 is finished, a parameter list of the current block is generated, and formatted data [ name, parameter list ], depth ] of the block containing the parameters is combined according to the format and added to the array to be finally output.

Step S710, the recursive queue 2 is processed.

Step S711: recursive queue 1 is processed.

Because recursion queue 2 is more closely associated with the context of the original building block, recursion queue 2 is processed first, followed by recursion queue 1.

Fig. 9 is a schematic structural diagram of a data formatting device provided in the embodiment of the present application. The data formatting device is used for formatting a graphic code component combination consisting of graphic code components. The data formatting device 900 in this embodiment corresponds to the data formatting method in the embodiment of fig. 3, so the specific implementation details in this embodiment may refer to the above embodiments, and the technical details are not repeated herein.

The data formatting device 900 comprises:

an obtaining module 910, configured to obtain a combination of graphics code components;

a formatting unit 920, configured to represent each graphics code component included in the graphics code component combination as formatted data in multiple data dimensions, so as to form the formatted data of the graphics code component combination.

Optionally, as shown in fig. 10, the formatting unit 920 may specifically include:

a first extraction module 921, configured to obtain execution role information of each graph code component in the graph code component combination; the graphic code components are grouped according to respective execution roles to form execution role groups;

a second extraction module 922, configured to obtain event information related to each graph code component under the corresponding execution role group; the graphic code components under each execution role group are grouped according to the respective related event information to form each event group;

a third extraction module 923, which extracts the type of each graph code component in the event group, the depth information indicating the nesting relationship of the graph code components, and the parameters of the graph code components with the parameters according to the ranking order;

a generating module 924, configured to form formatted data of each graphics code component according to the extracted information of each graphics code component, and form formatted data of a corresponding graphics code component combination according to the arrangement order.

Optionally, the third extracting module 923 may include:

a processing control module 9231, configured to control processing of each graphics code component one by one, and add the graphics code component determined to need recursive processing to the first recursive queue;

a first processing module 9232 for extracting information from each graphical code component outside the first recursion queue and incorporating corresponding formatted data;

a second processing module 9233 for extracting information from each graphic code component in the first recursion queue and incorporating corresponding formatted data.

Optionally, the second processing module 9233 may further include:

a parameter screening submodule 92331, configured to screen effective parameters of each graph code component one by one;

a process control sub-module 92332 for placing the graphics code component determined to require recursive processing into a second recursion queue.

In this embodiment, functional modules that can be optionally implemented are denoted by dashed boxes, which is not intended to be limiting.

Fig. 11 is a schematic structural diagram of a graphics programming system in an embodiment of the present application. The graphic programming system 110 may include:

a graphic programming unit 111 for providing a graphic programming interface for a user, and for receiving a user operation to combine the operated graphic code components into a graphic programming product;

the formatting unit 112, implemented by a data formatting device 900 shown in fig. 9, is used for formatting the graphic programming product or its related graphic code component combination to obtain corresponding formatted data.

In some examples, the graphical programming system may be a Scratch-based implementation, including the graphical programming elements, for interacting with a user to implement programming of building block combinations; the data formatting device in the foregoing embodiments may be integrated into the graphic programming system as a component or a module for formatting a graphic code component combination in the graphic programming product or its related reference answers, matching templates, and the like.

Fig. 12 is a schematic structural diagram of a computer device in the embodiment of the present application.

The computer device 120 comprises a memory 121 and a processor 122, the memory 121 stores thereon a computer program executable on the processor 122, and the processor 122 executes the computer program to perform the steps of the data formatting method or the sub-flow thereof (fig. 6, 7, 8, etc.) of the embodiment of fig. 3 or 4.

In some examples, the processor 122 may be a combination that implements a computing function, such as a combination comprising one or more microprocessors, Digital Signal Processing (DSP), ASIC, or the like; the Memory 121 may include a high-speed RAM Memory, and may further include a Non-volatile Memory (Non-volatile Memory), such as at least one disk Memory.

In some examples, the computer device 120 may be implemented, for example, as a server, a server bank, a desktop, a laptop, a smartphone, a tablet, a smart band, a smart watch, or other smart device, or a processing system formed by communicatively coupling such smart devices.

Embodiments of the present application may also provide a computer readable storage medium, on which a computer program is stored, the computer program executing steps of a data formatting method or a sub-flow thereof (fig. 6, fig. 7, fig. 8, etc.) in the embodiments of fig. 3 or 4, for example.

That is, the data formatting method in the above-described embodiments of the present invention is implemented as software or computer code storable in a recording medium such as a CD ROM, a RAM, a floppy disk, a hard disk, or a magneto-optical disk, or computer code originally stored in a remote recording medium or a non-transitory machine-readable medium and to be stored in a local recording medium downloaded through a network, so that the method described herein can be stored in such software processing on a recording medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware such as an ASIC or FPGA. It will be appreciated that the computer, processor, microprocessor controller or programmable hardware includes memory components (e.g., RAM, ROM, flash memory, etc.) that can store or receive software or computer code that, when accessed and executed by the computer, processor or hardware, implements the data formatting methods described herein. Further, when a general-purpose computer accesses code for implementing the data formatting methods shown herein, execution of the code transforms the general-purpose computer into a special-purpose computer for performing the data formatting methods shown herein.

In the above embodiments, the implementation may be wholly or partially realized by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer programs. The procedures or functions according to the present application are generated in whole or in part when the computer program instructions are loaded and executed on a computer. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer program may be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another computer readable storage medium.

For example, the functional modules in the foregoing fig. 9, 10 embodiments, etc. may be implemented in software; or may be implemented by a combination of hardware and software, for example, by a computer program running on a memory in a processor in an embodiment of the computer device; alternatively, the present invention may be implemented by a hardware circuit.

In addition, functional modules in the embodiments of the present application may be integrated into one processing component, or each module may exist alone physically, or two or more modules are integrated into one component. The integrated components can be realized in a hardware form, and can also be realized in a software functional module form. The integrated components described above may also be stored in a computer-readable storage medium if implemented in the form of software functional modules and sold or used as a stand-alone product. The storage medium may be a read-only memory, a magnetic or optical disk, or the like.

For example, in the embodiments shown in fig. 9 and 10, each functional module and each sub-module may be implemented by a single independent program, or may be implemented by different program segments in a program, and in some implementation scenarios, these functional modules may be located in one physical device, or may be located in different physical devices but communicatively coupled to each other.

In the description herein, references to the description of the term "one embodiment," "some embodiments," "an example," "a specific example," or "some examples," etc., mean that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the application. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, various embodiments or examples and features of different embodiments or examples described in this specification can be combined and combined by one skilled in the art without contradiction.

Furthermore, the terms "first", "second" and "first" are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one such feature. In the description of the present application, "a plurality" means two or more unless specifically limited otherwise.

Any process or method descriptions in flow charts or otherwise described herein may be understood as representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps of the process. And the scope of the preferred embodiments of the present application includes other implementations in which functions may be performed out of the order shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved.

The logic and/or steps represented in the flowcharts or otherwise described herein, e.g., an ordered listing of executable instructions that can be considered to implement logical functions, can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions.

For example, the data formatting method in the foregoing embodiments of fig. 3 and 4, etc., the order of the steps therein may be changed in a specific scenario, and is not limited to the foregoing description.

Although the embodiments of the present invention are disclosed above, the present invention is not limited thereto. Various changes and modifications may be effected by one skilled in the art without departing from the spirit and scope of the embodiments of the invention as defined in the appended claims.

Claims

1. A data formatting method is characterized in that the method is used for formatting a graphic code component combination consisting of graphic code components; the data formatting method comprises the following steps:

acquiring a graph code component combination;

2. The data formatting method of claim 1, wherein the plurality of data dimensions comprise: executing roles, events, sequential logic, and types; in the case of a graphical code component having parameters, the plurality of data dimensions further includes parameters.

3. The data formatting method of claim 2, wherein the formatting comprises:

4. The data formatting method according to claim 3, wherein said extracting, in the order of arrangement, the type of each graphic code component under the event group, the depth information indicating the nesting relationship thereof, and the parameter of the graphic code component having the parameter comprises:

accessing each graphical code component one by one;

5. The data formatting method of claim 4, wherein said extracting information from each graphics code component outside of the first recursion queue comprises:

screening the effective parameters of each graph code component one by one;

6. The data formatting method of claim 5 wherein said second recursion queue recurrently processes a higher priority than said first recursion queue.

7. A data formatting method according to any one of claims 4 to 6, wherein the graphics code components requiring recursive processing comprise at least one of: graph code components in a nested relationship; there are graphical code components of optional parameters.

8. A data formatting device for formatting a combination of graphical code components consisting of graphical code components; the data formatting device includes:

9. A graphical programming system, comprising:

a formatting unit, implemented by a data formatting device as claimed in claim 8, for formatting the graphical programming product or its associated graphical code component combination to obtain corresponding formatted data.

10. A computer device comprising a memory and a processor, the memory having stored thereon a computer program operable on the processor, wherein the processor, when executing the computer program, performs the steps of the data formatting method of any one of claims 1 to 7.

11. A computer-readable storage medium, on which a computer program is stored, characterized in that the computer program executes the steps of the data formatting method according to any one of claims 1 to 7.