RE: beans and JSPs and stuff...

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

Yes, and this is where the OO stuff comes in.  Yes, I had to write the widget 
code.  But only once!  The exact same widget code is used for every maintenance 
program.  And if I find I need a new feature, I add it to the base widget code 
and then guess what?  That feature is now automatically available to all the 
other maintenance screens!  Without recompiling or anything!

For example, I needed one of my fields to be adropdown rather than an entry 
field.  I added a new file that ties a field to a different data table.  Then I 
added code to the widget to create a dropdown list rather than an input field.  
Now, all I have to do is add a field to that file, and the new maintenance 
screen has a dropdown.

But guess what?  That code is now available to ALL my maintenance screens!  I 
simply add a record to the definition file, and I can add dropdowns 
RETROACTIVELY to any of the existing maintenance panels!

With a CGI approach, you'd have a separate CGI program to process each panel.  
To add the dropdown functionality, you'd have to go into each of those 
programs.  With OO, I don't have to do that - it's automatically inherited.  I 
add it to one, I get it in all.

I hope this explains a little bit how OO enables productivity.

Joe

P.S. You COULD do that in CGI.  You COULD.  You'd simply have to program a 
single, very smart CGI that acted like an object and could handle any 
maintenance screen.  Chances are, though, that most programmers won't do that.  
They'll have a separate CGI program for each screen.

---------- Original Message ----------------------------------
From: "Stone, Brad V (TC)" <bvstone@taylorcorp.com>
Reply-To: JAVA400-L@midrange.com
Date: Wed, 28 Feb 2001 10:51:26 -0600

>I would love to see some code, as I'm sure others would.  It seems that some
code has to be written somewhere with your widget.  Same goes for CGI as you
pointed out.  I just am not following how you say there is no code. 

To me, a widget could be a suprocedure that updates a file.  I wrote the
subprocedure.  now, I use it.  But I still had to write the subprocedure.
And you had to write the widget, right?

Brad

> -----Original Message-----
> From: Joe Pluta [mailto:joepluta@plutabrothers.com]
> Sent: Wednesday, February 28, 2001 10:13 AM
> To: JAVA400-L@midrange.com
> Subject: RE: beans and JSPs and stuff...
> 
> 
> Yeah, I know it sounds simplistic, Brad.  And it's hard to 
> explain sometimes - I almost can't explain it myself.
> 
> You see, my widgets themselves do the update.  All the 
> servlet does is tell the widget to update itself.  It needs 
> no knowledge of the database; all that knowledge is 
> encapsulated in the widget object.  Why is this important?  
> Because I can write generic servlets that process the widgets.
> 
> For example, I currently have a system that maintains four 
> files via the web.  All four files are maintained by the 
> exact same servlet.  All I do is pass it a server ID in the 
> HTTP Request (a hidden field in my form) and it automatically 
> creates a widget that wll update that file.  I recently added 
> a fifth file to the database - the servlet will not change!  
> At all!  When the Factory object creates the Server object, 
> all the information is encapsulated.  When I then create a 
> Widget from the Server, the Widget knows which Server it is 
> talking to.  The servlet then simply takes the HttpRequest 
> data, and passes it to the Widget, who in turn communicates 
> with the appropriate server.
> 
> You can do something similar in CGI, but you'll have to have 
> SOME code SOMEWHERE that checks to see which server needs to 
> be called.  That work is done for me automatically through 
> inheritance and polymorphism.  This is the essence of OO.
> 
> Tonight I'll try to post an example servlet, but just to give 
> you an idea, my servlets are roughly 20 lines of code.  Their 
> only purpose in life is to take the HttpRequest and pass it 
> to the widget, who then does what he needs to do.  The 
> servlet then passes control to the next JSP.
> 
> Joe
> 
> 
> 
> ---------- Original Message ----------------------------------
> From: "Stone, Brad V (TC)" <bvstone@taylorcorp.com>
> Reply-To: JAVA400-L@midrange.com
> Date: Wed, 28 Feb 2001 09:20:45 -0600
> 
> >>  And finally, CGI is output-only - my widgets also 
> > support the update
> > of data using the data input on the form, with pretty much no 
> > code in the
> > servlet.
> 
> Joe,
> 
> I don't follow this statement.  Are you saying that CGI programs can't
> update files, can't read forms, etc?  I'm sure some of my CGI programs
> update files using data read from input forms.  And not much 
> code to it
> either.
> 
> Brad
> +---
> | This is the JAVA/400 Mailing List!
> | To submit a new message, send your mail to JAVA400-L@midrange.com.
> | To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to 
> JAVA400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner: joe@zappie.net
> +---
> 
> +---
> | This is the JAVA/400 Mailing List!
> | To submit a new message, send your mail to JAVA400-L@midrange.com.
> | To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to 
> JAVA400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner: joe@zappie.net
> +---
> 
+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---

+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---