search

npruehs / tome-editor

Tome is a generic data editor for games supporting arbitrary input and output formats.
GNU Lesser General Public License v3.0
36 stars 7 forks source link

Feature Request: Changes to export templates #127

Closed pgrimsehl closed 6 years ago

pgrimsehl commented 6 years ago

Hi there :)

I'd like to see some changes/improvements to the current export template handling.

  1. The .texport file is accompanied by a set of files containing/defining the formatting of the contents of resulting output file. Right now, the base name and the path of all these files is impliclitly derived from the path and file name of the .texport file. While this might by convenient and logical at first glance, it results in unnecessary file duplication in a common use case. Imagine you have a project and want/need to export the data as multiple .ini files (each containing a subset of records). Since the .texport file defines what will be exported (by defining excluded records), we need one .texport file per .ini file that should be exported. Each of these .texport files must have a different name. Since this file name defines the name of the file set used for formatting, we need to duplicate all of these files for each .texport file. But in fact they all contain the same formatting definitions an do exactly the same thing: formatting the record data as .ini file. So it would really be nice to be able to define a path in the .texport file that points to the file set used for formatting, e.g. <FileSetPath>./template/INI File</FileSetPath>. So 'INI File' would be the the base name for the files. If the path is relative, it should be interpreted as relative path to the .texport file location, not the .tproj location.
  2. A new element in the .texport file <DefaultFileName></DefaultFileName>, where we can define the name that will be displayed in the file dialog after selecting an export template in Tome. Right now the name of the project will be used, which is not the export file name in many cases.
  3. A new element in the .texport file <IncludedRecords></IncludedRecord>, which is used similar to the <IgnoredRecords> element. The motivation to add such an element is the above mentioned use case (multiple .ini file export). Right now, we have to explicitly define all records we do NOT want to export. So if we have a project with 10 record groups, and want to export each group as one .ini file, we need to explicitly exclude 9 records in all other 9 .texport files. This is cumbersome and error-prone. And even worse, if we have to add another record group later, we have to update all existing .texport files to NOT export this new record. The <IncludedRecords> could work the following way: if the element is empty, the filter is not applied at all. If it contains elements, each record is checked against the items listed in the element during the export process, If a name matches the record name OR one of the record's ancestors, it will be selected for export. After the applying the include filter, the ignore list will be processed as usual - so ignore always wins.

What do you think about these changes?

npruehs commented 6 years ago

Hey @pgrimsehl!

Love all the suggestions, and I can see the use cases.

  1. Added in commit 14d3beb7d0523366b059c53577a02309e264c64c . The XML element name is TemplateFilesPath. The path is relative to the project location, though.

  2. Added in commit 4a3c6eda4287be4d80fdf2cc51d5cb2971f5edf2 .

  3. Added in commit 64c5efc91ef9188d5c9b1aa0a5d6478dbd466f17 .