tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From chas <pa...@skinnyhippo.com>
Subject Re: going from Zope to Tomcat, where are these features ?
Date Thu, 01 Jan 1970 00:00:00 GMT
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 
>> 
>>    <db_connections> - <sql_method> - <display_page>
>> 
>>    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:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


Mime
View raw message