Sample data editor feedback

So Johnathan Marshall is doing some work on a new sample data editor for Iguana. I’ve attached a screenshot.

The goals are to:

1. Give colorized text editor that is syntax aware – i.e. show XML tags, HL7 etc. colourized.
2. Make it possible to deal with inserting and editing line feed, carriage return and arbitrary hexidecimal characters and so on.

Attachments:

You must be logged in to view attached files.

We’re not sure how elaborate we should get with respect to the UI for inserting special characters and so on. Feed back is welcome.

In particular curious to know what problems people have dealt with that involve unprintable hex characters etc. I am not sure how much effort we should put into dialogs, choosers etc. for inserting special characters.

I think the model works reasonably well. As far as non-printable characters other than carriage-return, newline, and (although it’s technically printable but hard to differentiate from a series of spaces) tab, I think a 0xnn representation is fine.

As far as inserting those characters is concerned, is a drop-down list with the representation of the non-printing characters feasible? I don’t think you need to build a toolbar or anything too complex.

How portable will the clipboard representation be? The current method of displaying carriage-return and newline requires a bit of cleanup when pasting into anything but another message editor window.

Jeff Drumm ◊ VP and COO ◊ HICG, LLC. ◊ http://www.hicgrp.com

So:

1. Tabs
2. Carriage Return
3. New line

I thought we could have a expandable section in the tool bar that could show/hide a selection of special characters but it may be overkill if we are only talking the three main cases above and hexidecimal bytes.

In terms of clipboard representation my desire is represent the data in it’s binary format – so a carriage return would be 1 byte with the value 0x0D and so on. So it should make it portable to other editors.

Allow edit Sample Data in Hex mode (or at least to view it in Hex mode) is something to save Developer time.

A read only hex view would be quite easy for us to do. Doing a full blown hex editor… not so much 🙂

Eliot Muir wrote:

So:

1. Tabs
2. Carriage Return
3. New line

I thought we could have a expandable section in the tool bar that could show/hide a selection of special characters but it may be overkill if we are only talking the three main cases above and hexidecimal bytes.

Actually, I think you should also add 0x00 as NUL. I don’t think anything other than NUL and the other 3 characters previously discussed would be ‘well known’ enough to warrant a mnemonic rather than the associated hex representation.

I’m assuming you intend to do some sort of “auto-sensing” of message type. If yes, then in the case of HL7 v2.x, could you dynamically base the delimiter highlighting on the 5 bytes found after ‘MSH,’ rather than hard-code them in the parser?

In terms of clipboard representation my desire is represent the data in it’s binary format – so a carriage return would be 1 byte with the value 0x0D and so on. So it should make it portable to other editors.

Exactly what I was hoping to hear 😀

Jeff Drumm ◊ VP and COO ◊ HICG, LLC. ◊ http://www.hicgrp.com

I think for colourization logic what we probably should do is add a column to the sample data which defines the MIME type like:

1. text/xml
2. text/json
3. text/edi
4. text/plain

edi being for HL7, X12 etc. Probably only makes sense to store the bit after the slash unless we anticipate having bin/base64 or something? When the data is imported it would make sense to run a heuristic over it which could try and guess the data format and set the column value for the mime type. In the editor view there would be a drop down box for the mime type so that if Iguana guessed it wrong the user could change the setting (which would be saved with the sample data).

The only drawback with that design is it’s a pain adjusting the sample data layout – we have done it before – it requires having a initialization stage in Iguana to check sample data databases and upgrade them to have the extra column.

Sorry got a little side tracked – ah yes – the darn MSH delimiter redefinition… yes it’s doable. Still need to know that one is dealing with HL7 vs. XML etc. guess text/hl7 is definitely needed vs. text/x12 and text/edi….

Eliot Muir wrote:

So:

1. Tabs
2. Carriage Return
3. New line

I thought we could have a expandable section in the tool bar that could show/hide a selection of special characters but it may be overkill if we are only talking the three main cases above and hexidecimal bytes.

Perhaps include LLP delimiters (0x0B and 0x1C) as well. These sometimes get mixed up in copy/pastes.

Hi Garry,

I think we’ll be okay with those since they will show up nicely as hex characters