XML option browser

Mahks

@general_zod Yes, search function ... I have been pondering that. The question is this; If it is only a left hand search then you miss many references to mid string stuff ie; a search for "sneak" would miss "Defending Subs Sneak Attack". But if you do a full string search it would be very easy to get a huge list of references. I thought I could do the latter and only return a unique link for each, not sure how helpful that would be. Still pondering...

Mahks

@general_zod said :

I see, "s" is for scenario. So it is triplea scenario option browser. Personally I would just exchange scenario for xml. TAXOB

How about just XOB?

LaFayette

Very nice work.

We could do a special commentary syntax in the source code where attachments are defined. On each build we could fire up a script that then scrapes these comments and produces a JSON that is then delivered to a 'data' section of the website and would then be available as a javascript variable. This is pretty similar to how the maps page is populated: http://triplea-game.org/maps-list/maps/

@Mahks if you can handle the front-end part, with jekyll, and assume you have such a JSON variable, I could do the backend scraping and deliver the JSON. https://github.com/triplea-game/triplea-game.github.io

Thoughts?

redrum

Interesting. So I think the real question here is do we have general consensus on replacing POS2 XML with this approach? As I don't think we want to try and maintain both.

General_Zod

@mahks

XOB sounds ok to me, nice and short.

As the search goes, it should be a search of all information in the right pane for maximum usefulness. The left pane has two sorting modes so that piece is more manageable from search standpoint. If you could replicate the common find or find next methods where it only searches up or down from current cursor location. That would be ideal because one can just bypass a lot of the stuff they know they don't want as results. In this case the cursor position being whatever is highlighted in the left pane, but I think it would need to recognize if the left pane is currently in alphabetical or hierarchal modes during the search to function well.

@redrum

I vote for XOB if it comes down to a choice of one or the other as it applies to maintenance.

Mahks

@lafayette Having the JSON based in/on the source code comments would be ideal. If the developers update those comments when changes are made.

It may be a lot of work to get the data into those comments in the first place though.

The HTML page is pretty straight forward. Could be maintained by anyone with HTML. I could do it for now.

But I think the most important thing is getting the data in a portable format.

redrum

@LaFayette I don't want to put the comments in the engine source code as then no one but developers would ever maintain it. Its better in a place that map makers can also contribute to.

Mahks

@redrum I just realized he may have meant the POS2 file.

But... once the data was up to date. there should be no need to add to it unless the engine is being modified.

I do not know how you go about change approvals, but who ever approves the code change should update the data at the same time (document the change)

redrum

@mahks Possibly but that's not how I understood his comments.

In theory, that's true but having the flexibility for non-developers to add more hints/info/corrections I think would always be beneficial.

Today, when a developer makes a code change that influences the XML then we update the POS2 XML with an example and comment. If we moved to a different way to store that info like JSON in a repo that would be fine as well and in theory work the same way. I just don't want to have multiple places to update.

Cernel

@redrum I would surely not remove the PoS2 stuff. To reduce overhead, it may be acceptable to have the practice to update primarily this thing only, as mandatory for anyone making any changes, letting PoS2 up to personal initiative to keep it updated, just like any regular maps (most likely it won't happen, or with averagely year long delays, I imagine).
I'm surely not a sponsor of the principle of having to update multiple things, but stuff being inside the xml itself I think it is really the easiest way to use, for fairly experienced mapmakers, that already know about everything (and just need some memory refresh and copy-paste).

Cernel

@redrum I agree that people that make changes should be obliged to update no more than 1 place, and possibly an easy one to manage. Reducing overhead and confusion is of paramount importance.
Just I would not delete the PoS2 bible, but making a clear mention that this is not the main reference, a link to the main reference, and telling people that everyone is free to pull updates to PoS2, if they find something not in line. Likely, people reading PoS2 will read that, so you won't get too many bug reports about PoS2 being wrong, but just possibly people pulling changes to it, in case.

General_Zod

@cernel

I don't think anyone was saying delete POS2 at all. Just preference of XOB for future updates.

redrum

Yeah, not saying we would delete POS2 XML just essentially stop updating it.

@Hepps @Frostion Any thoughts on this? Do you feel a tool like this is better for map makers than POS2 XML?

Cernel

@redrum I think PoS2 is better if you know about everything already, and just need copy-pasting and refreshing your memory.

Just be sure to, like, clarifying in PoS2 itself that it is not necessarily updated, to avoip people assuming it is (I mean a clear notice about that at the start of the xml).

theredbaron

I thought I should offer some encouragement here. This looks phenomenal, and is close to what I had envisioned in the past could be added to the TripleA website. I would suggest that we offload POS2 XML to this new format, while keeping a bare-bones POS2 XML file that would need very little updating.

POS2 is still needed to provide an example implementation for many of these options, as well as sample code, but I think this solution will fill a different role, maybe replacing POS2's reference function. If we do it right, we might even be able to deep link to this reference from within the code comments in POS2 XML. However, as Cernel is, I'm wary of change, as I've gotten used to working with POS2 XML. So we'll have to be sure to get this right.

LaFayette

@redrum

@LaFayette I don't want to put the comments in the engine source code as then no one but developers would ever maintain it. Its better in a place that map makers can also contribute to.

I don't think that is the right concern, but I would want it to be so that developers would keep the source data up to date when adding new attachments, but open for anyone to modify and improve the documentation at the same time.

We essentially have this model with triplea_maps.yml. While not perfect, it has worked out that more than just developers can update the file.

I checked out the source code further, it's not in good shape to accept more information as either additional javadocs or java annotations, so keeping this info in java source files I would agree is not a good one.

@mahks said in XML option browser:

The HTML page is pretty straight forward. Could be maintained by anyone with HTML. I could do it for now.
But I think the most important thing is getting the data in a portable format.

I generally agree, but I do think there are a some additional important questions to decide/answer:

how to integrate this as an official tool so we can keep it up to date now and for the long term?
will the web server hosting technology integrate with the rest of the TripleA infrastructure, will it add another server to be managed and maintained?
will there be overhead or delays in deploying any data updates to the web server?

I like the tool as presented and I think it would make sense for it to be part of the official project. I think two really good options to do that would be either:

Similar to the maps yaml file, host a yml file that is updated when we update source, on updates the yml data would be transformed to JSON and uploaded to website (we do this about exactly for the maps.yml data today).
Host the HTML file independently from the source code but on the github website directly. Github.io uses a jekyll, it can render HTML natively.

The first option has greater one-time setup cost, but data is pure from presentation layer and can be updated at same time as source, so lowest maintenance cost over the long term compared to the second option (which is also completely viable too).

Any third option (is very welcome), but would have some challenges to solve for the concern of server maintenance overhead in addition to keeping the data well maintained over time.

Mahks

@lafayette

"how to integrate this as an official tool so we can keep it up to date now and for the long term?"

Currently the data is embedded in the html page. I did that so it would not need server access (the page can be used off-line). The data could be split off into a second file and just loaded by the html page. If you go with the yml to JSON idea, this would be the way to go.

"will the web server hosting technology integrate with the rest of the TripleA infrastructure, will it add another server to be managed and maintained?"

I see no reason why the page would need its own server. No security is needed, just drop the html file and the JSON file (if separate) on an existing server.

"will there be overhead or delays in deploying any data updates to the web server?"

I have no experience working with files that are editable by a group, so I don't know how you would manage version control. On my own projects I just upload the new file to the server.

"Similar to the maps yaml file, host a yml file that is updated when we update source, on updates the yml data would be transformed to JSON and uploaded to website (we do this about exactly for the maps.yml data today).
Host the HTML file independently from the source code but on the github website directly. Github.io uses a jekyll, it can render HTML natively."

Currently the XOB html page does not need server access. The page uses javascript to re-render the page without requiring server generated pages (like the wiki does). So the html base file would rarely change. It would only be the JSON file that would need to be kept up to date.

I was not familiar with YAML, After a quick peek at the wikipedia page I see that it is the mother of JSON.
So it is possible to import a yml file into javascript, though not as clean as just loading a JSON object.
You could just use JSON rather than the YAML format negating the need to convert.
If you are not familiar with JSON have a look. In fact you could keep the data within the html file (just use it instead of the yml).
To see what I mean download the XOB file (rather than loading the page by left-click) and view it in an editor. I suspect the data format will look much like the YAML you are used to.

One issue that was a pain in JSON, and could be in YAML, was the examples. I wanted the examples (when viewed in XOB) to be indented and formatted as you would see them in the XML. XML elements can be confused with HTML elements when a browser renders a page. The only way I found of formatting the data so the examples look correct (and could also be copied to the clipboard in a usable format) was to place them in a TEXTAREA. And this meant I could not use HTML to do the indenting, I had to use tabs. Tabs are illegal in JSON (and YAML) so they all had to be escaped (along with all double quotes - which the XML uses). ARGHHHH...

So my point with all that was, examples cannot just be dropped into JSON or YAML, there is a bunch of fiddle required.

redrum

@mahks @LaFayette My thought is put a JSON or YAML file at the root of the tripleA project just like the triplea_maps.yaml. Then have the necessary HTML/JS/CSS in the website project that pulls in that file and create a new area in the website to show this map making wiki. Thoughts?

Mahks

I could not load https://triplea-game.org/triplea_maps.yaml, where can I find it?

redrum

@mahks https://github.com/triplea-game/triplea/blob/master/triplea_maps.yaml