RE: Getting to the bones with Java and .NET

Aaron,

The inflexible project structure was one of the big complaints in Eclipse 
1.0/WDSC 4.0.  I believe there was some stuff done in 2.0/5.0 and more in 
2.1/5.1.  I do everything in WDSC, so I have no problem adapting to the 
project structure.  I just create a Java project, and then using Windows, 
I drag and drop from the root of my source code to the project.  This 
copies everything into my workspace and I work from there.

Eclipse makes a contract with the plugin providers that it is going to do 
things like notify them of every change made in the workspace.  That is 
why if you change code directly on the filesystem you have to do a refresh 
in Eclipse for it to recognize it.  This is so that Eclipse can fulfill 
its end of the contract.  In 2.0, 2.1 and 3.0 they are just continiuing to 
evolve that concept so that it can be flexible while still maintaining the 
contract.

There are a lot of Struts books on the market now, most show you how to 
build a complete application.  Part of the point of Struts is that it is a 
framework, so you do not exactly "write code".  Struts implements MVC 
(Model View Controller).  The Model is your business logic.  It should 
just be Java code that has no dependencies on Struts, or where it is used. 
 It could be using JDBC, or calling RPG, or EJB's or Web Services.  This 
is all obviously code that you write, but you do it in a way that doesn't 
really matter how you implement it in terms of a web browser or fat 
client.  It doesn't need to know about it.  Struts acts as the Controller 
and allows you to glue together your View with your Model.  It is mostly 
controlled via XML configuration files.  The XML tells it which of your 
Java classes to call in certain situations.  These classes are small Java 
classes you write that inherit from Struts.  These classes are typically 
pretty easy to write.  They are where you make use of your Model layer. 
For example, perhaps you construct your Customer object and tell it to 
return all Customers in Ohio.  You take the results and store them in the 
Request object and return a value that is usually just a success/failure 
value but can be more complicated.  Struts then looks at this value and 
routes onward to the appropriate View component which is usually a JSP. 
The JSP is then just configured to pull the data out of the request object 
and display it to the user.

It is actually a lot of work up front because there are all of these 
little pieces to put together.  But once you get about 50-60% into the 
project it starts to really pay off. The Struts controller can be easily 
reconfigured by changing the XML file.  So in the above example if you 
decide you now want to route the user to a different JSP, you just create 
the JSP and change the XML to point to the new file.  Your Java code 
doesn't change.  Likewise, you could enhance your Java to return multiple 
values that determine which JSP it routes to and maybe you return a 
different value based on the type of user.

The beauty of Struts is that once you learn it you see that it is very 
simple.  The entire project only consists of a small amount of classes. 
What they have done is taken a very commonly used design pattern known as 
the "Front Controller" and implemented it in a way that lets you 
"configure" it with XML files.  A lot of people that do not use Struts 
wind up writing a front controller anyway, because it is a powerful and 
useful pattern.  What they do not do is write all of the code to configure 
it via XML.  That is the advantage to going with Struts.  Of course other 
benefits are all of the graphical toolings that have been created which 
are essentially just graphical ways to represent the XML configuration 
file.

Mark