RE: [WDSCI-L] Getting to the bones with Java and .NET

["Bartell, Aaron L. (TC)" <ALBartell@xxxxxxxxxxxxxx>]

That is by far the best explanation I have ever heard of Struts!  Probably
because it was tailored to me:-)  I think I know why I could never find a
place for them, because I am a "communications" programmer for the most
part.  I don't write a ton of business logic, but more get something from
point a to point b.  For instance I have a Tax Calculation Servlet that
takes in an XML stream, parses it, and calls RPG with the values.  RPG hands
it back the calculated tax and the Servlet then in turn writes that to
standard out.  For stuff like this, is there a good place for Struts?  This
is a relatively simple example  I realize.

It sounds like you use Struts when you don't want your Java objects
dependant on the implementation of another, correct?  Is Struts purely Java
centric?  So could the Java program that inherited from Struts make an XML
call to a non Java procedure?  Or is it tightly coupled within the Java
language?

Excellent explanation!  Documentation on these things is so hairy.  They
always take such a formal approach.  The Java technologies need a site like
http://www.w3schools.com to explain things in simple statements and not make
you wait to get to the meat of the concept.

That was also a good explanation on how the Eclipse Java stuff works.  WHY
IS THAT NOT IN THE DOCUMENTATION WDSc team?!  And if it is in the docs, why
is it buried so deep - I haven't come across it yet. . .  Something as
simple as how the developers of Eclipse were thinking when they developed
the flow of a Java project would be great!  The only documentation I have
seen takes you one itty bitty step at a time through the process of creating
a Java project and doesn't explain a lick of concept in the process. <going
to look at the docs some more>  Just looked under the 'Concepts' in the help
under 'Java Development' and it doesn't explain at all what Mark just told
me.  When your IDE strays from the other IDE's that you are trying to pull
people away from, you should document how "new" concepts work.  I have used
both JBuilder and Sun ONE Studio, both of which do their projects similar to
each other, but completely different from WDSc.



Aaron Bartell

-----Original Message-----
From: Mark Phippard [mailto:MarkP@xxxxxxxxxxxxxxx]
Sent: Friday, July 25, 2003 11:13 AM
To: Websphere Development Studio Client for iSeries
Subject: RE: [WDSCI-L] 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




_______________________________________________
This is the Websphere Development Studio Client for iSeries  (WDSCI-L)
mailing list
To post a message email: WDSCI-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/wdsci-l
or email: WDSCI-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/wdsci-l.