This got long-ish as I'm partially thinking out loud about this
work-in-progress. Sorry. The whole thing got blown out of proportion
late last week and I shouldn't be doing this with Struts at all, I
think. More of a Dave's Java Playground project, this.
Adam Hardy wrote:
if you have a whole package of DAOs (doing the CRUD stuff), all
inheriting the Torque base class which implements your DAO interface,
and you change over to Hibernate, then surely you must write a whole
new package of DAOs for Hibernate, not just the base class?
The DAO stuff is written by Hibernate (I might not be using the right
acronym, I suppose), and I haven't fully refactored my classes yet, but
in a nutshell:
public interface ICrudDelegate {
// CRUD operations
public Object getById(final String omClass_, final String id_);
public void deleteById(final String omClass_, final String id_);
public List getList(final String omClass_);
public void saveOm(final Object om_);
public void updateOm(final Object om_);
// CRUD method retrievers
public Method getUpdateMethod(final String omClass_);
// [... plus others like that ...]
}
So I have a DefaultTorqueCrudDelegateImpl class that does all the Right
Things for Torque. I also have a DefaultHibernateCrudDelegateImpl class
that does all the Right Things for Hibernate (although I suspect I have
a fair chunk of refactoring yet to do).
Actual it's more complicated than this, as I have a single Action that
does all the CRUD based on Ruby on Rails-style URLs :
/${prefix}/${table_name}/${command}[/${id}] and have a IHandleCommands
interface:
public interface IHandleCommands {
public boolean isCommandHandled(final String cmd_);
public Object handleCommand(final String cmd_, final Map cmdParams_)
throws UnsupportedOperationException,
CommandHandlerException;
public Class[] getHandlerSignature();
public Object[] getHandlerParams(final Map cmdParams_);
}
and currently a single implementation, StrutsCommandHandler. My single
CRUD action packages up relevant arguments (mapping, form, request,
response, my crud config (see below), etc) into the Map and hands it off
to the StrutsCommandHandler, which instantiates and uses the delegates
as described above.
So a chunk of my config file might look like this:
<crud-mappings>
<crud prefix="Admin">
<form tableName="Event"
omDelegate="com.pingsite.delegates.DefaultTorqueCrudDelegateImpl"
omClass="com.pingsite.om.Event"
/>
<form tableName="AnnouncementType"
crudHandler="com.pingsite.crud.handlers.AnnouncementTypeCrudHandler"
omDelegate="com.pingsite.delegates.DefaultTorqueCrudDelegateImpl"
formClass="com.pingsite.struts.forms.AnnouncementTypeForm"
omClass="com.pingsite.om.AnnouncementType"
/>
<form tableName="ProductCategory"
crudHandler="com.pingsite.crud.handlers.StrutsCommandHandler"
omDelegate="com.pingsite.delegates.DefaultTorqueCrudDelegateImpl"
formClass="com.pingsite.struts.forms.ProductCategoryForm"
omClass="com.pingsite.om.ProductCategory"
</crud>
<crud prefix="User">
<form tableName="AnnouncementType"
formClass="com.pingsite.struts.forms.UserAnnouncementTypeForm"
omClass="com.pingsite.om.UserAnnouncementType"/>
</crud>
</crud-mappings>
There are also the typical hooks you'd expect; things before the form is
displayed (so I can pre-populate dropdowns, etc.), things after the form
is submitted (like tweaking my form's checkboxes into integers for my
MySQL Torque stuff), blah blah blah. Except for the generation of JSP
chunks (currently barely handled by a Ruby script) it's a configuration
file change to add a table into the CRUD processing system, which is neat.
Totally out of control, though, and I'm not entirely sure I've really
accomplished anything except get better at design and reflection. It's
been a VERY interesting exercise, though!
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
