Return-Path: Delivered-To: apmail-jakarta-tomcat-user-archive@apache.org Received: (qmail 95782 invoked from network); 31 Oct 2001 00:54:13 -0000 Received: from unknown (HELO osaka.betaversion.org) (192.18.49.133) by daedalus.apache.org with SMTP; 31 Oct 2001 00:54:13 -0000 Received: (qmail 21161 invoked from network); 31 Oct 2001 00:56:44 -0000 Received: from nagoya.betaversion.org (192.18.49.131) by osaka.betaversion.org with SMTP; 31 Oct 2001 00:56:44 -0000 Received: (qmail 18880 invoked by uid 97); 31 Oct 2001 00:53:26 -0000 Delivered-To: qmlist-jakarta-tomcat-user-archive@jakarta.apache.org Received: (qmail 18700 invoked by uid 97); 31 Oct 2001 00:53:22 -0000 Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Users List" Reply-To: "Tomcat Users List" Delivered-To: mailing list tomcat-user@jakarta.apache.org Received: (qmail 10225 invoked from network); 30 Oct 2001 17:51:04 -0000 Message-Id: <200110301751.MAA01087@interlock2.lexmark.com> X-Lotus-Fromdomain: LEXMARK@LEXMTA From: dhay@lexmark.com To: "Tomcat Users List" Date: Tue, 30 Oct 2001 12:47:41 -0500 Subject: Re: going from Zope to Tomcat, where are these features ? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N You can easily do this without J2EE. Lots of people using Struts do so. The Struts action classes act as adaptors between the model (database) and the view. You can access the beans that encapsulate the sql calls here, use them to get the data from the database, add it to a form bean and display it in the jsp. Struts provides a great MVC separation. Cheers, Dave chas on 10/30/2001 08:48:51 AM Please respond to "Tomcat Users List" To: "Tomcat Users List" cc: (bcc: David Hay/Lex/Lexmark) Subject: Re: going from Zope to Tomcat, where are these features ? Thanks for the reply Dmitri, >> 1. In Zope, you can create permanent database connections >> with a click of a button. It comes part and parcel of >> the application server. >> In Java, you can create your own database pool. >> (eg. http://webdevelopersjournal.com/columns/connection_pool.html) >> But does Tomcat really not come with its own database >> pool manager built-in ? > >J2EE uses the javax.sql.Datasource for connection pooling - normally this >would be controlled at an application server level, but the following >document talks about how to use it in tomcat (I'm not sure of the extent >of the datasource discussion here): > >http://jakarta.apache.org/tomcat/tomcat-4.0-doc/jndi-resources-howto.html Great, this is what I was looking for. It also covers the equivalent of Zope's Mail Adapters for mail support. Other than the lack of simple GUI for configuration, this is perfect. >> 2. In Zope, you create a "SQL Method", which is an object that >> basically contains a SQL statement and queries it against >> one of the database connections in your pool. >> The advantage of such "SQL Methods" is that they can be fully >> tested/debugged standalone before using their output within >> your pages. The result is also cached and you can easily specify >> the time to cache, or the number of results to cache. >> All it takes is your SQL query and 4-5 clicks of the mouse. > >sounds like an entity bean? Am I way off track? An entity bean encapsulates a lot more functionality than Zope's SQL methods. An entity bean, as I understand, takes care of all the business logic for a business object.... .. whereas the SQL methods to which I refer just take care of SQL statements (inserts/updates/deletes etc) and cach the results. A business object in Zope might use multiple SQL methods. So, it appears to me that this is the way to go with Java/JSP - wrap everything inside beans. I don't mind doing this but find that it doesn't lend itself as easily to prototyping and rapid application development. >> For example, I have to agree with the following article - >> http://www-106.ibm.com/developerworks/java/library/j-webdata/ >> - that the scriptlets and even the DBTags code leave your >> JSP pages a complete mess. > >(o: I think you'll find most ppl agree with you there. Glad to hear it's not just me. >> In short, there has to be a better, cleaner way of separating >> >> - - >> >> where Display pages use the results of SQL method which >> in turn use DB connections. The article above suggest the >> cleanest way to separate these is with "includes" - including >> separate pages which take care of form validation, database >> queries, etc. > >One option for providing this sort of architecture would be: > >db - jboss - struts/tomcat - view > >jboss - http://www.jboss.org >struts - http://jakarta.apache.org/struts > >note that everyone has their favourite application server, I'm just >suggesting jboss/tomcat as a very easy solution (which we use). OK. I had hoped to leave EJB/J2EE and JBoss for a later date - there was a quote somewhere that 70% of projects that use EJB really don't need to. However, if that's going to give me much cleaner demarkation of business logic from presentation, and make each component easier to debug/test individually, then it's worth a try.... I may as well get my feet wet now, and will check JBoss. Thanks again, chas -- To unsubscribe, e-mail: For additional commands, e-mail: -- To unsubscribe, e-mail: For additional commands, e-mail: