tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From d...@lexmark.com
Subject Re: going from Zope to Tomcat, where are these features ?
Date Tue, 30 Oct 2001 17:47:41 GMT


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 <panda%skinnyhippo.com@interlock.lexmark.com> on 10/30/2001 08:48:51 AM

Please respond to "Tomcat Users List"
      <tomcat-user%jakarta.apache.org@interlock.lexmark.com>

To:   "Tomcat Users List" <tomcat-user%jakarta.apache.org@interlock.lexmark.com>
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
>>
>>    <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>








--
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