Codic Engine.Net:  Technical

What Are You Using?

I am using an ASP.Net front end to host the Codic Engine.Net.  The rest are class files written in VB.Net after two years of experimentation ala a Windows version of Codic Engine.  Classes are extended, methods are overloaded, and the such.

Mind if I Look at the Code?

Yes.  I will only trust special people.  You are most likely not one of them.  I am pro-Microsoft; MS has made it this far because someone with greater ability can't use their code and take it to heights MS cannot go.  Once I release stuff on open source, I lose all control over the project.  If someone else were to make a better Codic Engine, I might not be able to match it.  Then, all my efforts here would have been a waste and I would be miserable for years on end.  This is my project, and I don't want people taking that away from me.  However...

What is Open Sourced?

Once I get the encoder up and running, I will make certain things open source.  I will have the code sets in XML, as well as the web service running with HTML and XML outputs.  All code sets are open source, per request to the code's creator, also displayed within the Codic Engine's "View Code Set" page.  I may also make the programming code available that I use to add a code set to the Engine.  I doubt this, as I probably would have transferred the code sets to a database by then.

Things will become open source upon request.  If I don't want to make something open source, I'll tell you.  Keep in mind I am extremely paranoid about losing control and credit over making something open source.  This knowledge might want to be free, but I won't let a bird stretch its wings without being assured it will return to me.

Class Files:

The Engine needs seven class files to decode a single code set, one of which is the code set itself.  If I won't make it open source, what about a description of the class files?  Fine with me; I also have a UML diagram for those who ask me really nicely:

Control:  This is responsible for taking in what a user enters, determining what code set is being used, instantiating that code set, and sending that code set as an argument to the Decoder's decode() method.  It also converts the query string back to a valid code and vice versa.  Keep in mind URL query strings and hyperlinks will not use certain symbols that are utilized in some code sets.

Decoder:  This is the heart and soul of the Engine's decoding process, as its name leads one to believe.  This one controls the high-level functions of decoding and does not actually decode the code.  It has four methods: decode() takes in an instantiated code set (type CodeSetNew) and tells the code set class to decode a segment of code.  It returns the decoded code's HTML.  Segmenter() breaks a code up where there are spaces.  However, some code sets use [] to denote text, so it is keyed to wait for a closing bracket before segmenting that part.  This, again, is crucial to making the Engine work.  TrimThis() simply trims the entered code and makes it tidy.  FilterDuplicateKeyLetters() takes care of duplication.

CodeSetNew:  Everything revolves around this class, once the code is segmented.  It is the core of the Engine; the fuel that makes it run, the pistons that produce results--the other, preparation classes are simply the spark plugs to make this ignite.  I should note that this is a data type; it is not instantiated.  This is what makes the polymorphism possible, so I don't have to copy methods based on variable types when I pass the instantiated code set around in other classes.  All code set classes extend or inherit (same thing) from this class.  Almost all decoding logic is housed in this class.  Decode() and findKeyLetter() are its major methods.

Translation:  This class houses a segment's translated information.  This class contains the segment that was ultimately translated and the HTML display code for the output.  When I build XML functionality into the Engine, this class will be where half of it will take place.

KeyLetter:  A keyletter stands for the letter in a code set that stands for a question--follow?  For instance, you have the question, "What state are you from?"  The letter that goes with that is "St", and tells the user that is the question you are answering.  This is the keyletter.  The keyletter class stores all metadata and data about one key letter in the code set.  Therefore, I have an array of keyletters within the code set's class.  This class also stores all keycodes for that keyletter, discussed below.  It has eight overloaded constructors to deal with any situation.  Since its creation, I only needed to add one more piece of metadata to deal with an obscure keyletter from one code set; this was how accurate my planning and knowledge about code set translation has come since I built the Windows version of the Engine.  I have methods to perform various things on that keyletter and its keycodes.  Most of it is information-gathering, no irony intended.

KeyCode:  This is a single answer possible under a keyletter.  I have 11 overloaded constructors for this.  This class's only purpose is to hold a single keycode and store all these values. 

GeekCode:  Or any other code set.  When I make a code set, I have a class named after it.  This class's constructor instantiates some metadata about the code set, such as who made it, how many keyletters I have, how many universal modifiers I have, etc.  It then calls a method that adds the code set's keyletters to an array, adding keyoptions to those keyletters on the way.

Encoder:  This one keeps track of the question number and mid- to high-level stuff with encoding the codeset.

EncodeSegmenter:  This one does the low-level stuff, such as keeping track of what was selected and where.  That's very important for the encoder.

MyCodes:  Overall view, add, and delete functions for handling user codes.