Lexi wysiwyg editor ~ Fall 2012
Lexi is a WYSIWYG (What You See Is What You Get) editor. This project was for my Object Oriented Design Patterns Class. Thus, each of the different assignments required use of explicit design patterns to make the final product very modular and easy to add on to .Each of the six steps is detailed below. Prior to those details though, there is a slideshow of the progression that the editor went though for each new set of functionality.
Lexi #1: Composite and StrategyThis was the initial version of Lexi. Through the implementation of the patterns in this assignment I was able to create an editor window that would display data in rows and columns, nested if desired. See the screenshots above for the result.
|
Part 1 Files![]()
|
Lexi #2: DecoratorThis was the second iteration of Lexi. This version added, through the decorator pattern, the ability to create embellishments. Embellishments in Lexi are borders and scroll bars. These allow text to be separated from the rest of the document, as well as it being longer than the bounding box itself, with the use of the scroll bar. See the screenshots above for the result.
|
Part 2 Files![]()
|
Lexi #3: Abstract factory, factory method, and singletonThis iteration of Lexi added the ability to create buttons and labels through the use of factories. Factories in this iteration were key. This is because we had two different colors for each of our items (labels and borders). Using the factory, as a singleton, we were able to easily switch the color of the items that we were creating by changing an environment variable. By using the environment variable and the Singleton pattern we were able to enforce a singular look and feel on our environment (either all green items or all red items). See the screenshots above for the result.
|
Part 3 Files![]()
|
Lexi #4: BridgeThis iteration of Lexi was very interesting. It gave a method from which to use of single interface while being able to switch in and out the backed code for a section of the project. in this instance we wanted to be able to switch between Swing and AWT as our Windowing Systems. By using the Bridge we were able to enforce a single interface standard while keeping the client code from directly being able to use either the Swing or AWT interfaces. This further enforced the singular look and feel for our windows. See the screenshots above for the result.
|
Part 4 Files![]()
|
Lexi #5: Command, Chain of responsibility, and prototypeThis was the most fun iteration of the Lexi editor. This version allows for keyboard and click interaction with the editor. The user can use the keyboard to either increase of decrease the size of the font, while buttons in the document become clickable. This interaction makes the editor much more complex, and really showcases how much work needs to be done to create a fully functional text editor form the ground up. See the screenshots above for the result.
|
Part 5 Files![]()
|
Lexi #6: Iterator and VisitorThis final iteration of Lexi allows for all of the Glyphs in the document to be walked. The ability to walk a document is very important. In our case we used it to just extract all of the full words from the editor and print them to standard out, but in the case of a real editor, this functionality will among other things allow for the implementation of a spell checker. See the screenshots above for the result.
|
Part 6 Files![]()
|