[Tool] Design Document Parser & Civilisation Editor for XML/JSON

[Radagast.]

Quick update. Have fixed the jqeury issue with the cache. Now no longer researcher frustration. (I hope.)

Still missing some core features. Like save. But the main obstacles that stopped us from settling down in our queer lodgins researchers' home have been put aside.

[FueledByOCHD]

If you could hepha, check my spelling with my toolkit would be great help in your spare time

[Radagast.]

Updated. Finally webkit is supported now too (google chrome et al. support).

Sorting,

Grouping,

Live Filtering

finally working.

New site, too.

Now we need a save functionality and it's ready to use. But I think of storing all data in the XML + JSON instead of the Database. This way we could still manually edit files locally and commit to the server. (or logon to the server and edit there)

I have to think about it a bit more.

[Radagast.]

I settled on a compromise:

- store in database, (to minimise lag due to permanent parsing of the XML + JSON and because we have to resolve conflicts and the database minizes the overhead we otherwise to fight with)

- when saving a new database state, nothing is committed to the versioning system.

- a separate button to export the current database research data into XML + JSON files. Here the commit happens too.

This procedure requires me to logon to the server to manually resolve conflicts should there arise some. Though this is quite unlikely as for this to happen a part of a file has to be edited both manually and via the Web interface at the same time.

The filesystem will look like this now:

/civilization.1/.                    /.hg                    (versioning)                    /...                      (other files of this civilisation) /civilization.2/.                    /.hg                    (versioning)                    /...                      (other files of this civilisation) 

The database:

IF EXPORTED:1. Read structure from any of the above civilisation folders/repositories.2. If structure read successfully (i.e. folders were not empty):    2.1   Clear Database.    <-- better do that directly after exporting from the research tool to the filesystem.    2.2   Generate Database.3.ELSE IF NOT EXPORTED (read: committed) YET SINCE THE LAST EDIT:1. Load database.

This project is declared as cancelled. The concept may have been useful if using the web interface and only the webinterface.

We will switch to Java Server Pages which will allow us to reuse my day-before-yesterday terminated 2-year-project. That means we can parse the Documents into XML, though this makes only sense in a one-directional way. I.e. never may anyone alter the civilisation XML/JSON for as long as the design document isn't finished.

Or rather: For as long as the document shall be automatically turned into XML/JSON.

It will also allow us to upload in DOCX/ODT and have a PDF as well as a preview image generated automatically from it.

---

The files will be handled as follows:

• Github repository. (simply the quicker and cheaper solution than setting up a system ourselves, and we don't really have secrets in that matter - in contrary, we live from public discussion.)

• Github repository checked out to server filesystem.

• Filesystem directly being parsed and altered without the intermezzo of a database.

• In the process of parsing we keep track of each civilisation's structure in the same way as currently in the PHP web civ editor (i.e. using kind of XPath for both JSON and XML).
• This most elaborate markup willl be stored and each civilisation will show that fields are missing or 'could' at least be put into service.

The last point will ease maintenance and gives a clear overview of what tags/elements/attributes are possible, without losing time by having to look it up.

All the other features remain. I.e. the web UI and sorting, filtering and grouping and highlighting and image linking per node ...

Later we can think of direct integration into Pyrogenesis, but I fear:

• It would never make it into the main version. (also because it had to go into the main game and not into Atlas to allow ingame edit, which furthermore had to be togglable and might not be adapted because of being clutter and maybe lessening performance.)

• Researchers might not be aware of how to commit their changes upstream.

• We had to start the game when doing research. Something I dislike. It's better to have a web UI and be able to research and get read out aloud by your telecommunication apparatus the historical texts. Allowing you to just put it into the central Web data with ease.

I'm not yet sure as to when the repository - which was checked out to the server from github - should be committed. Either put a button there (as we also need a commit message, or perhaps even generate the commit message automatically out of the files which were changed. In the latter case we could even commit on each Save procedure of the researcher. Though I don't know if that's a good idea if many researchers are working and saving simultaneously.)

Don't worry, we are getting to a real solution slowly. All before was simply not covering the usecases we have to expect and thus was a dead end.

Edited May 17, 2014 by Hephaestion

[Radagast.]

The topic will be renamed from

Civilization Database & Export into XML/JSON

into

Design Document Parser & Civilisation Editor for XML/JSON

[Lion.Kanzen]

Is important take screenshots and talk about state of version. I can try?

[Lion.Kanzen]

What happen with this?

[Stan`]

Not much since @Radagast. left.

[Lion.Kanzen]

But isn't bad idea. A civ maker.