|
As a web programmer I often faced the problem of how the project resorces had became an unmanagable mess. At last I decided to make a small smart tool that helps looking up my source files and matching them to related other resources. Developing a robust, database driven application it seems a good idea to keep your database statements in a single property file, in form of key = value pairs, such as sql.t_machine.insert=insert into t_machine (id, mcname, headnum) values (?,?,?)To use this form you should only read the property file into your java code then you can easily build up a PreparedStatement object instance and do the neccesary parameterizing work with values received from an html form. Properties props = new Properties(); So far, so good, but what, if you have hundreds of statements in the property file and additionally some of them turns up in more than one java classes? If you changed something - or anybody else working on the project changed something - (for example the parameter count or order an sql statement waits for) you should know ALL related java classes, JSP and html pages related that statement to follow the changes. Everybody knows database programmers and their needs to change tables and queries as often as java developers go to have a cup cofee. Not to mention the always-changing customer needs. So, I'm sure your property file won't be a static one. And as the sql statements change so your code must be changed! Soon you will need looking up one by one the statements from the property file and java classes that hadling and parameterizing them. I think you're starting to understand why you need a smart and handy QueryMapping tool... Well, let's see what I'm talking about! Let's have a little sample web app with only a few JSPs providing the user with forms to send insert, update and select statements to a database. When user requests a page - usually clicks a link, icon, menu bar element etc. - a lot of things might happen in the background. For example a database select statement which produces a list or table on the upcoming screen. When user finished his work on the page - usaully put some data in form elements - clicks submit and new request is then sent to the web server. And again one of your java classes might does some database operation. Here's a very stupid web GUI to help you imagine: The
user clicked on the 'Newly
Ones' Blackboard' menu item on the left (highlighted in red) and the
answer page appeared in the right. The upper table and its data of the
right frame was produced by a database operation. User is allowed now
to select
one record from the list to rewrite data. When he or she finished,
clicks the 'Record' button to save data to database. |
The toolQuery Mapper Tool has four views on a JFrame containing a JTabbedPane with one tab for each view. The tabs in order are:
The Application View can contain some logical order of the application. I chose the menu hierarchy but it's the programmer's choice. If you're looking something based on application menu map or only be able to find a function from here - start using at the Application View. You can see that Application View's level one nodes matches to our previously presented "Two Storks Fly & Drive" sample application's menu structure. If you click on a node you see two types of sub-nodes: on request page and on submit form. With these we can divide sql statements two groups: the ones, that are executed before rendering and their result will be displayed on the upcoming page, and the others, that run after submitting the form. The leaves in the tree are the sql property strings from our property file. The whole view gives developer an image of what part of the application the given statement is called and which user interaction -requesting a page or submitting a form - will make the query run. Property View shows keys of the sql statements from your property file, keys that your java code uses too.
Expanding nodes here display the related logical entries (names from the menubar that user clicks to start a function). And on lower level there are 3 types of source files that related to the given statement. Three types are:
In my terminology a setter is java or jsp file, that handles the values received from user form, from a datasource. Setters might do validating but every time they do substituting the question marks of a PreparedStatement with user inputs. And last but not least processors are those java classes (even jsp pages), that process the given statement - they contain executeQuery(), executeUpdate(), executeBatch() etc. method calls. Code View shows the application complete file list grouped by file types. Under every file name you can see expanding nodes with the related statements.
If you start with Application View and click a menu item, then you choose a menu-related sql statement then step on Property View you will see the selected statement highlighted. Expand its children, choose a resource file, click on it then change to Code View. Code View will then reveal the selected resource and all the statements that affects this resource. Stepping views by views you can filter the information you are interested in or you study your projects structures from a developer's point of view.
The whole stuff wouldn't worth any at all if we could't check up what real sql statement is under the hood of property file's keys... That's why we have a Table View. Table View shows all of the application's sql statements grouping under tablenames. Certainly the primary reference is the property key also here, but click on it, and the real statement is revealed. If you continue reading I walk you through the process as I developed this application with NetBeans 4.0. |
|
This contains the following topics:
Setting up a new application with NetBeans IDE 4.0
If you have the JDOM API downloaded you have to let NetBeans know abaout it, and that your project needs it. Click on the Project tab in the IDE (or press Ctrl+1 if it's hidden) right-click on your project's name and choose Properties. In the Build section choose Compiling Sources. Click Add JAR/Folder. Now you have to show NetBens the folder where you installed JDOM. Under JDOM installation directory in the build subfolder click jdom.jar an Open. You have to follow these steps anytime you want a thirdparty or your own .jar file add to the project resources. Creating xml and property files for the project
Compile and run the project
How to run the project with command line args
|
|
I hope you succesfully build up the Query Mapper Tool application followed the previous steps and now you're playing a little with it. I tried to write a fully-commented code, so wouldn't go deeper into the details. Using the tool you can easily understand its how-tos and by property and xml files you can develop your own version if needed. Since one always can make an application better I just wanted to give an idea. The possibilities have really no boundries. For example, with little effort it could be joined together an editor from which the user could open files directly for editing. Anyway the problem is still there - I face everyday with it. Maybe once it would really worth a while to write a robust and comfortable tool to solve this. Or make this kind a tool a part of NetBeans? |