|
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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.