<The previous article in this series | The table of contents of this series | The next article in this series>
We Created a UNO Extension Project Skeletons (and UNO Additional Data Types Project Skeletons) Maker
About: UNO (Universal Network Objects)
About: LibreOffice
About: Apache OpenOffice
About: Java Programming Language
The Implementation of Our UNO Extension Project Skeletons (and UNO Additional Data Types Project Skeletons) Maker
The same with the previous scene.
What will be the implementation of our UNO extension project skeletons and UNO additional data types project skeletons maker?
The contents of the files we have to create are mostly fixed, and our tool's task is to imbue some strings at fixed positions in those files. Considering the characteristic of the task, I think, XSLT would be an appropriate thing to use.
So, will our tool create xml data that consist of the properties described above (actually in the preceding article), and convert the xml data to the objective files based on some style sheets?
Yes. As we can see from the descriptions of the properties above, the properties are appropriate to be organized in xml data: multiple implemented UNO interfaces can be organized as child elements of a defined UNO component, etc.
Are we creating a single xml tree for all the objective files, or a specific xml tree for each objective file?
Ah, I didn't even think about creating a common single xml tree; of course, doing with creating only one xml tree has a merit, but many objective files wouldn't need most of the tree.
Hmm, . . . well, OK.
What will the layouts of spread sheets on which the property values of projects are set?
One spread sheet will represent one project, and we will need three types of spread sheets: for UNO extension projects with UNO additional data types, for UNO additional data types projects, and for UNO extension projects (without any UNO additional data type).
What exactly are they like?
-Hypothesizer opens a spread sheets document file.
This sheet is for UNO extension projects with UNO additional data types.
This sheet is for UNO additional data types projects.
This sheet is for UNO extension projects (without any UNO additional data type).
The name of each sheet is the project name.
-Rebutter look at those spread sheets.
Green cells explain where we should put each property value in.
Please don't change the text contents and the background colors of those green cells: our tool will see them and judge where parameter values are set, based on them.
So, if I change the color to red because I hate green, . . .
The tool won't work properly.
And if I translate the text contents to another language, . . .
The tool won't work properly.
And please don't remove any of those green cells, especially the last one, which says, 'End'. The 'End' cell is the cell at which our tool stops interpreting the sheet. If that cell is removed, our tool will search the sheet for it to the last row of the sheet.
May I insert a column at the first column?
Definitely not! Our tool will search those green cells in the first column.
May I insert rows as we need?
Yes. If there are many 'other classes paths', for example, you will have to insert rows.
If I don't need any 'other classes path', may I remove the empty row under that 'Other Classes Path Expressions' green cell?
No, you may not: that empty row is required. That's the same with the other sections. For example, if there is no defined UNO interface, leave an empty row where there are property values rows in the above image.
What if I didn't?
Well, I won't elaborate on what would happen when your setting wasn't what the tool expects, for each case. . . . I'm sorry, but I don't intend to make the tool fault-tolerant (making it fault-tolerant would require much more time). So, if you don't set property values as the tool expects, I can't guarantee what would happen . . . (although I don't expect very bad thing to happen)
Well, such a principle may be permissible according to expected users.
Anyway, there will be no technical problem in implementing our tool. In the perspective of UNO programming, it's just a matter of how to read spread sheet cells.
OK.
-Hypothesizer begins to implement the tool.
. . .
. . .
. . .
Ah, as I am trying to interpret sections of data on a spread sheet into instances of some structures in Java, it is rather cumbersome. . . . To think of it, as such logics are reusable, I will implement them in a utility class. In fact, the 'thebiasplanet.unoutilities.documentshandling.spreadsheetsdocumentshandling.UnoSpreadSheet' class will have methods that handle them.
You mean a Map, for example, by 'structure'?
Not all Maps are equal. We need String to Strings-Lists-List Maps, String to String-to-Strings-Lists-Map Maps, and String to String-to-String-Map Maps.
I don't see what they are, at first glance . . .
Java expressions may be more clear: 'Map <String, List <List <String>>>', 'Map <String, Map <String, List <String>>>', and 'Map <String, Map <String, String>>'.
I understand them now.
And we will also need 'List <String>'.
Is 'Map <String, Map <String, List <String>>>' enough? I mean, shouldn't' we generalize it as 'Map <String, List <String>>', 'Map <String, Map <String, List <String>>>', 'Map <String, Map <String, Map <String, List <String>>>>', . . .
Although we need only 'Map <String, Map <String, List <String>>>' in this case, I think, we should generalize it as a utility. And I will also parameterize the String part.
Ah-ha.
-Hypothesizer begins to implement the utility class.
. . . Well, generics is unhandy in a case like this.
A case like what?
Well, . . .
As the argument became long, it is described here.
. . . So, it's finished with the utility class. I will return to the implementation of the tool . . .
-Hypothesizer resumes to implement the tool.
All right. It's here, and how to use the zip file is here.
-Hypothesizer builds necessary projects.
Where is the spread sheets document for setting property values.
It's in the 'execution' directory of the 'projectSkeletonsMakerUnoExtensionToDisclose' project.
And you have to import the Basic library that is in the same directory into LibreOffice, and set values into two variables in the Basic module, 'ProjectSkeletonsMaker'.
-Hypothesizer imports the Basic library, 'TheBiasPlanetBasicLibrary', and opens the 'ProjectSkeletonsMaker' module.
The first two '???' marks are places where we have to set values, I guess?
Yes. We have to set the directory of the style sheets and the directory of the development base directory.
The directory of the style sheets is the 'execution' directory of the project, 'projectSkeletonsMakerUnoExtensionToDisclose'; the directory of the development base directory is whatever a directory that we want to be so.
Yes. But as Gradle build scripts and Ant build files that are created by the tool use our common Gradle build scripts and Ant build files, unless those common files exist in the specified development base directory, those Gradle build scripts and Ant build files won't work as they are.
-Hypothesizer sets those values, and opens 'ProjectSettings.ods', and pushes the 'Make' button of the 'projectMakingTestUnoExtension1' sheet.
. . . Have the files been made?
Yes. They should have been.
What now?
It's already a valid project that can be built successfully: executing the 'gradle' or 'ant' command on the project will build the project. However, usually, before that, we will want to define some methods in the UNOIDL files and implement those methods in the Java source files.
Can we also just execute the 'gradle' or 'ant' command on the development base directory?
Hmm, it depends on which types of projects we have created: if we have created a set of a UNO additional data types project and a UNO extension project, we will have to build the UNO additional data types project before the UNO extension project, which an execution of the 'gradle' or 'ant' command on the development base directory doesn't guarantee.
Ah-ha.
And note that if there already exist UNOIDL files or UNO component Java source files, the tool will give you a java.nio.file.FileAlreadyExistsException error. You know, you won't want a file that has implemented some methods brutally replaced.
So, the tool doesn't kindly save the existing files and create new files?
Well, it doesn't, at least for now. You will have to rename the existing files yourself.
<The previous article in this series | The table of contents of this series | The next article in this series>
