RE: Attempt to reduce/alleviate the loosely coupled nature of Str uts

[rh...@rdg.boehringer-ingelheim.com]

Hi Laine,

I am wrestling with the same scenario- I have many forms, each of which may
contain 50 or more properties. It is a real hassle trying to keep the entity
bean matched up with the action form and then with the JSP.  Please let me
know if you come up with a solution... until then how about a little design
discussion :)

I have made some decisions on the design of our application to address this
exact problem. I noticed that in most cases our ActionForms contain the same
properties as the entity bean, or one or more entity beans. If you use the
same names for the properties in both the EJB and the ActionForm you can use
the Struts property copy utility. I perform this copying process from within
a session bean. This still requires that the JSP properties match the
ActionForm properties which match the entity EJB properties- all of which
must be done manually. But this cuts out the recommended intermediate object
suggested in the Struts docs- which I find redundant and unnecessary (JSP
<--> ActionForm <--> Business Object <--> Entity EJB), and results in a
simpler design (JSP <--> ActionForm <--> Entity EJB). Now the session EJBs
have to be aware of Struts (or an additional interface) and return the
appropriate Struts-specific objects. Not a big deal in my opinion since you
can make this design flexible and extensible by using a factory. There are a
few issues to watch out for with this design- the biggest problem I have is
when using non-String data types. In this case I have to add some extra
setters and getters to the ActionForm in order to communicate with the
Struts JSP tags and make these conversions. This brings me to my second
point...

The ActionForm needs to be automatically generated and support basic type
conversions.  I think there is talk about doing this in the next version of
Struts right? There is reference to this in the TO-DO 1.1 list- "ActionForms
with Dynamic Properties" The ActionForm would need to be created from some
type of factory that would  parse the JSP and look for tags and dynamically
create the appropriate object. Then you could do a copyProperties to get the
data from this object over to a business object or entity EJB. If you are
going in the other direction, a session EJB should be able to call this
factory to create the object needed for rendering the JSP.  And one more
thing... I don't think JSP tags should require that a property be present in
the ActionForm in order to render themselves. If this property is missing,
they should still display correctly(but with a null value) and not throw an
exception.  So if the ActionForm was generated automagically, then we would
end up with a even more condensed design:  JSP <--> Entity EJB. Of course,
there would be an intermediate object accessible if needed, but from the
development perspective these would be the only structures that needed to be
manually synchronized.

I guess my response really is not that helpful to your immediate problem,
but I wanted to provide my opinion on this matter as well.  Struts is
already a great product- I think this type of functionality would really
enhance maintainability of Struts applications.

-Bob


-----Original Message-----
From: Laine Donlan [mailto:ldonlan@elogex.com]
Sent: Monday, April 02, 2001 3:42 PM
To: 'Struts' (E-mail)
Subject: Attempt to reduce/alleviate the loosely coupled nature of
Struts


All -

I was hoping to tap the brain trust out there for any ideas on how to
address the following problem:

In the system I am currently working on there is a large amount of code
generated based on a database schema.  For example: for any given table
in the schema an entity bean is generated with some basic functionality
as well as a javabean (maps to the columns in the table) that is used to
pass data between the back-end to the front-end.

>From a Struts perspective the majority of our forms maintain a 'has-a'
relationship with on or more of these javabeans.  Therefore the
properties in the JSP's map directly into the generated javabeans.  This
has been working beautifully thus far.  However, we made some pretty
significant schema changes for the next release of our product, and am
now facing the problem of re-working the system to function against the
new schema.

The main problem is, as the entire code base is being re-worked we
cannot deploy and run the system.  Therefore, it is not a trivial task
to search through the JSP code to determine what properties will break
the next time a page is run.  Just as a baseline for the size of the
system we have roughly 500 jsps that use Struts tags and 50 + form
objects that may have changed structure based on the newly introduced
schema.

My initial thoughts on this were to somehow scan through the JSP's and
attempt to resolve the proper form associated with it and then attempt
to call the appropriate getters and setters using the Struts facilities.
I would preferably like to piggyback on the work already being done by
the JSP compilation services (Jasper, etc) but am having a little
difficulty determining if I can insert some process along the way or
mimic the function using the services components.

The eventual out put of such a process could be something as simple as a
report of what properties will be problematic and in what pages they
live.  Then work could be done to pro-actively fix these places while
the rest of the system is being re-worked.

Any thoughts would be greatly appreciated.

Laine