Model morph type, map from FW Data

[hahn-kev]

Morph types are limited in FieldWorks, the name can be customized, but there's a limited set of them. To handle that we will use an enum on the entry to indicate it's morph type. Something like this:

enum MorphTypeKind
{
Unknown,
bound root
bound stem
circumfix
clitic
discontiguous phrase
enclitic
infixing interfix
particle
phrase
prefix
prefixing interfix
proclitic
root
simulfix
suffixing interfix
suprafix
Other
}

class Entry
{
  MorphTypeKind MorphType {get;set;}
}

(feel free to suggest a better enum name).

That covers the entry side, but we also need to model the object as well in order to use the correct names/labels that users specified.

class MorphType
{
MorphTypeKind Kind {get;set;}
MultiString Name {get;set;}
MultiString Abbreviation {get;set;}
RichMultiString Description {get;set;}
string LeadingToken {get;set;}
string TrailingToken {get;set;}
int SecondaryOrder {get;set;} //there might be a primary order? but it's not in the UI
}

take a look at ComplexFormType and copy that for the rest. It should have an Id and other properties that our normal entities have. The kind should be determined by comparing the IMoMorphType.Guid against the well know GUIDs in MoMorphTypeTags when mapping to and from FW.

Included in this issue is implementing the mapping from the FW Data API. There should be APIs for Create, delete update, List, GetByKind, for the morph type. And the morph type should be mapped into entries.

The CRDT API can throw for now and will be done in another issue.

[rmunn]

I like MorphTypeClass rather than Kind since I see linguistic literature referring to "classifying" morpheme types, but naming anything "Class" can be difficult because class is almost always a reserved word in any OOP language. I also like just plain MorphType for the enum, and a longer name like MorphTypeData for the class that carries the name, abbreviation, and so on.

[rmunn]

Work started in #1857. @hahn-kev, let me know what you think of using MorphType for the enum and MorphTypeData for the class with the name, abbreviation, etc.

[rmunn]

The SecondaryOrder is used for sorting a list of ShortName objects (ShortName is the name that should be displayed in a chooser list in the FieldWorks UI). The primary search key is the name of the object (usually something like the citation form or lexeme form), but for items with the same name, the secondary search key is "SecondaryOrder of the morpheme type, times 1024, plus homograph number". This ensures that all prefixes will group together, all suffixes will group together, and so on.

Also, the SecondaryOrder of each morpheme type is assigned a fixed value in the NewLangProj.fwdata template, as follows:

0 - discontiguous phrase
0 - prefixing interfix
0 - infixing interfix
0 - suffixing interfix
0 - particle
0 - phrase
0 - clitic
0 - circumfix
0 - root
0 - stem
10 - bound root
10 - bound stem
20 - prefix
30 - proclitic
40 - infix
50 - suprafix
60 - simulfix
70 - suffix
80 - enclitic

Most of those 0's seem like omissions to me, but that ordering has been pretty consistent since FieldWorks 6.0. Seems to me we should keep the SecondaryOrder info around in the MorphTypeData classes, and maybe use it when we need to order things, but not allow users to mess with it.