Hello,I am new to Struts. Have worked on a few tutorials and have attempteda few simple exercises. Currently I am working on an exercise where Ihave to access a MySQL database from the main jsp page ( which asksthe user for name) and display the data related to the user.I would be really thankful if somebody pointed me to some onlineresource where I could study more about this stuff and attempt theexercise. Tutorial etc.Cheersros

ros wrote:> Hello,> > I am new to Struts. Have worked on a few tutorials and have attempted> a few simple exercises. Currently I am working on an exercise where I> have to access a MySQL database from the main jsp page ( which asks> the user for name) and display the data related to the user.> > I would be really thankful if somebody pointed me to some online> resource where I could study more about this stuff and attempt the> exercise. Tutorial etc.Write a class, or package of classes, that contain the JDBC calls that create the connection, prepare the SQL statement, execute the statement and retrieve the results.  That layer or class will translate the ResultSet or other return values into objects that the rest of the application can use.  (This is what frameworks like Hibernate do.)In your Action class create a data access object (DAO) of this class or one of the package types, (Interfaces are best for the compile-time type.)  Use that instance to execute your data operations.There are JDBC tutorials and other documentation amply available on the web. GIYF.-- Lew

On Apr 5, 6:36 am, Lew <l...@nospam.lewscanon.com> wrote:> ros wrote:> > Hello,>> > I am new to Struts. Have worked on a few tutorials and have attempted> > a few simple exercises. Currently I am working on an exercise where I> > have to access a MySQL database from the main jsp page ( which asks> > the user for name) and display the data related to the user.>> > I would be really thankful if somebody pointed me to some online> > resource where I could study more about this stuff and attempt the> > exercise. Tutorial etc.>> Write a class, or package of classes, that contain the JDBC calls that create> the connection, prepare the SQL statement, execute the statement and retrieve> the results.  That layer or class will translate the ResultSet or other return> values into objects that the rest of the application can use.  (This is what> frameworks like Hibernate do.)>> In your Action class create a data access object (DAO) of this class or one of> the package types, (Interfaces are best for the compile-time type.)  Use that> instance to execute your data operations.>> There are JDBC tutorials and other documentation amply available on the web.> GIYF.>> --> LewThanks for the hight-level explanation Lew. Trust me, it helps a lot.I'll get working on the exercise and shall post here the problems (Iknow there will be!) that arise.Thanks again.Ros

> On Apr 5, 6:36 am, Lew <l...@nospam.lewscanon.com> wrote:

>> ros wrote:

>>> I am new to Struts. Have worked on a few tutorials and have attempted
>>> a few simple exercises. Currently I am working on an exercise where I
>>> have to access a MySQL database from the main jsp page ( which asks
>>> the user for name) and display the data related to the user ...

In Struts, the way you would generally do this would be:

1. JSP submits to a Struts action, passing validated username via form
2. Struts action assembles data from the database based on the username
3. Data put into request scope attribute - request.setAttribute(...)
4. Action forwards to the JSP that will display the data
5. JSP "view" displays the data put in the request

....
>> Write a class, or package of classes, that contain the JDBC calls  ...
....
>> In your Action class create a data access object (DAO) of this class or one of
>> the package types, (Interfaces are best for the compile-time type.)  Use that
>> instance to execute your data operations.

But then, for anything more than a trivial application, you should think 
about separating your data access code from your action classes.

Having data access code in actions couples your choice of 
view/controller framework, i.e. Struts, to your choice of data access, 
i.e. JDBC/DAO. Delegating the data access to another layer of code makes 
it easier to change your DAO implementation, e.g. to Hibernate, later on 
and promotes re-use of your data access code.

So, in your action classes, instead of code like this ...

	try {
		MyDAO dao = new MyDAO(connection);
		Person p = dao.fetch(id);
		...
	}
	catch (java.sql.SQLException e) {
		...
	}
		
.... you have code more like this.

	try {
		Person p = MyDelegate.getPerson(id);
		...
	}
	catch (com.mycompany.NotFoundException e) {
		...
	}

.... which is business-focussed rather than data access focussed and 
doesn't change if you move to something like Hibernate or EJB.

-- 
Regards,

Richard

Richard Senior wrote:> Having data access code in actions couples your choice of > view/controller framework, i.e. Struts, to your choice of data access, > i.e. JDBC/DAO. Delegating the data access to another layer of code makes > it easier to change your DAO implementation, e.g. to Hibernate, later on > and promotes re-use of your data access code.JDBC/DAO classes are arguably a better choice than Hibernate.You bandy about terms like "promotes re-use of your data access code" as if that were actually possible or beneficial.  Data access code is tightly tied, and inevitably so, to the data model for an application and the logic performed on the data.  This militates against re-use of data stuff, although I do reuse abstract classes that handle connecting, disconnecting and the like.  But then, I wrote those classes, so they don't suffer the weaknesses an O-R Moreau creates.As for switching from an RDBMS direct access to Hibernate, bleah!  That's for people who don't get set algebra and the power of SQL.  Every time I've used one of those "O-R" frameworks I've spent more time and effort fighting its limitations that I would have done using JDBC and SQL.  Having done it both ways, I feel secure in this assessment.Object views recapitulate the flaws of the network model database, which lost to the relational model a couple of decades ago for good reason.  (I've worked on network model databases, too.)  Hibernate is a waste of time and energy and locks you away from the value of SQL.I change databases on the back end all the time, but that's apples to apples.   I would not trade the power of an RDBMS for the crippling bloat of a Hibernatish framework.-- Lew

Lew wrote:> Richard Senior wrote:>> Having data access code in actions couples your choice of >> view/controller framework, i.e. Struts, to your choice of data access, >> i.e. JDBC/DAO. Delegating the data access to another layer of code >> makes it easier to change your DAO implementation, e.g. to Hibernate, >> later on and promotes re-use of your data access code.> > JDBC/DAO classes are arguably a better choice than Hibernate.I don't disagree. I wasn't in any way recommending Hibernate. But coupling your data access mechanism of choice into Struts is bad practice on larger applications.To quote the Struts HOWTO "How To Access a Database" http://struts.apache.org/1.3.8/faqs/db-howto.html ..."Ideally, all the database access code should be encapsulated behind the business API classes, so the framework doesn't know what persistent layer you are using (or even if there is a persistence layer). It just passes a key or search String and gets back a bean or collection of beans. This lets you use the same business API classes in other environments, and also to run unit tests against your business API outside of a web environment."> You bandy about terms like "promotes re-use of your data access code" as > if that were actually possible or beneficial.  Data access code is > tightly tied, and inevitably so, to the data model for an application > and the logic performed on the data.Of course re-use of data access code is possible and beneficial! The quote above alludes to the same. It's basic programming good practice:   * Put calls to DAOs into a Business Delegate layer and call the delegate rather than duplicating code and database level exception handling across action classes.   * Make calls to the same API in other applications.Is that not re-use?And yes, of course data access code is tightly coupled to the data model and perhaps even the database. That's precisely why it should be accessed via a clean business interface - so that your application isn't coupled in the same way!-- Regards,Richard

Richard Senior wrote:> I don't disagree. I wasn't in any way recommending Hibernate. But > coupling your data access mechanism of choice into Struts is bad > practice on larger applications.I agree with pretty much everything you said in your post.....> Of course re-use of data access code is possible and beneficial! The > quote above alludes to the same. It's basic programming good practice:> >   * Put calls to DAOs into a Business Delegate layer and call the > delegate rather than duplicating code and database level exception > handling across action classes.> >   * Make calls to the same API in other applications.> > Is that not re-use?I don't reuse all of the same API in other applications.  I copy the same base classes and re-extend to application-specific logic and entities.  So it is re-use and it isn't.  Because each application winds up with different data and logic, I can't reuse everything, and what I do resuse will just be the interfaces and abstract classes.So yes, it's reuse at one level.  I should have specified that I meant that the concrete implementations may not be reusable.> And yes, of course data access code is tightly coupled to the data model > and perhaps even the database. That's precisely why it should be > accessed via a clean business interface - so that your application isn't > coupled in the same way!Yes - I practice this.  I believe in isolating the data layer more than I do in reusing it.But the entities, the facts of the data model, perforce are present in every layer, front to back.  If you need someone's hair color, that'll be reflected in the input forms and surface validation, the business logic and the data structures.  An app that doesn't care about hair color will not be able to reuse those factors.Likewise the logic - if you care about changing hair color your object model and behaviors will be very different from those of an app that tracks payroll deductions.The reuse is at the abstract layer; the devil is in the implementation details.-- Lew