Sandeep Deb's Home Page
Universal Editor
  One for all... all for one
I grew up learning Java on TextPad. For some reason, I always felt that IDEs cripple you by making your life too easy. Also there was this fear of getting too vendor specific and feeling lost if the crutches are pulled out. I hated Visual Age for Java. My philosophy was working good till the time I got introduced to J2EE. My ambition to remain IDE neutral was shattered when I realized that most of the application servers were tightly coupled with the IDEs, just because the application server had it's proprietary XML configuration requirement. I hated using vendor specific IDE just because of a simple XML (Heard of WebSphere AAT??) !! I wanted an XML editor in which I could load the DTD and the tool would guide me create an XML out of it.

There was XMLSpy, but it was too expensive for me. I tried IBM's Xeena but it was too boisterous. There was such a dearth of cheap (free) and light XML editors. Finally, I thought of building my own! It wasn't too difficult and at the end I had a 150KB editor in which you could load any DTD and chug along.

Computationally the excercise involved broadly the following items:

a)A mechanism to parse the DTD and make a parse tree out of it

b)A mechanism to convert the parse tree to a deterministic finite automata

c)An UI workbench to help the user load a DTD and then help him by traversing the DTD and recommending the possible elements and attributes

No sooner had I got down on the design board, a strange thought struck me. I realized that if I could decouple the formatter (XML formatting) and persistence (File) from the UI, I could make the UI very generic, very pluggable and not limited to XML editing. So, this is how my train of thought went:

Data by it's very nature is structured. The structure can be very comfortably expressed in a tree structure and DTD can be effectively used to constrain the structure of the tree. Now, the data tree can be transformed by one or more formatters and can be consumed by one or more consumers. A XML formatter and a File persister are just one of the producers and consumers. This thought makes the UI very generic, in fact so generic that it can be used as UI dialogs in many applications. For example, let's say I want to create a search dialog to capture data relating to the search query. I can express my data requirements as: 

<!ENTITY % bool "(true|false)">

<!ELEMENT SearchForm (SearchFilter) >
<!ATTLIST SearchForm
                searchString        CDATA #REQUIRED
                direction           (forward|backward) "forward"
                caseSensitive       %bool; "false"
                wholeWord           %bool; "false" >

<!ELEMENT SearchFilter EMPTY>
<!ATTLIST SearchFilter
                nodeNames       %bool; "true"
                attNames        %bool; "true"
                attValues       %bool; "true"
                descText        %bool; "true">
With this, I can ask the UI to use the above DTD to capture the search data and once done, call back a pre configured object with the data tree. After the callback it's the application's responsibility to make use of the data.

Ok, I think you get the line of thought. You can download the source and binary for playing around.

 
Executable Jar >> You can download the executable Jar file by clicking on the image. This can be run by double clicking on it or by exeucting it using the java -jar com.sandy.util.cpe.app.CPEApp command.
 
Source Code >> You can download the source code by clicking the image on the left. Please feel free to chage, update and enhance the code as per your needs.