New struts user - status Qs

[rf...@on-the-net.com]

I just got a small system running using sturts on a mysql database. 
A few Qs:

1) Is there an archive of the email list anywhere ?

2) Anyone done anything to help rapidly create an application ?

I created a Q&D application builder to help get started.  It reads the
structure of Mysql database and creates the Form/Action classes as well as
a list and edit JSP and the action.xml -- any place I can put it for other
users ? 

(note: it's in perl and uses the 0.5 release, and is probably written
totally wrong, BUT it does creating working aps)

Later ...

Rich Roth --- On-the-Net

Direct:  Box 927, Northampton, MA 01061

Email: rich@on-the-net.com              Url: http://east.on-the-net.com
      ~~~   i-Depth lets you Add Instant Depth to your Website    ~~~
      ~~~  7 day free trial at: http://www.i-depth.com/signup.htm ~~~

RE: Design question

[Juan Gargiulo <ju...@mindstech.com>]

Craig,

My understanding from what you responded me about ActionForm being EJBs was
wrong, sorry about that. However, your explanation in the last email was
extremely useful.

Thanks,

juan

-----Original Message-----
From: Craig R. McClanahan [mailto:Craig.McClanahan@eng.sun.com]
Sent: Friday, November 10, 2000 4:35 PM
To: struts-user@jakarta.apache.org
Subject: Re: Design question


Juan Gargiulo wrote:

> Craig,
>
> Thanks a lot for your answer.
> I think that I'm very close of defining the architecture for my
application.
> Using action classes as adapters and session EJBs for business logic
sounds
> good.

Yep.

> Also using EJBs as actionforms is a good idea because they are a good
> target for object reuse. But it is not clear to me how do this. I don't
see
> how struts is going to know how to get one of this EJB-actionforms from
the
> context. How I specify the name of the home for the EJB-form to the action
> class (to the struts descriptor)?
>

Actually, I do *not* believe it is a good idea to re-use an EJB as an
ActionForm.  In fact, this will be somewhat more difficult in 1.0, now that
ActionForm is a class rather than an interface.

The reasoning behind my belief goes like this:

* An ActionForm is part of the view layer of MVC, not the model
  layer like an EJB (or a regular JavaBean that represents
  persistent data).

* The sole purpose of an ActionForm is to maintain the state of
  all the input variables on a particular form, so that you can
  reproduce the form pre-filled-in if the user made an error that they
  need to fix.  This matches the expectations of users who are used
  to GUI-based client server apps, that never make you retype any
  input except the stuff you did wrong.

* Because of the above, the "domain" of an ActionForm does not
  necessarily match any existing EJBs or model layer JavaBeans.
  It is not uncommon to have inputs from a single form that will
  ultimately cause updates to more than one undelrying EJB or
  model bean.

* Using a separate class for the ActionForm means you can
  change the underlying organization of your model beans or EJBs
  without impacting the view layer (although there might be modest
  impacts on the Action classes that copy things back and forth).

* In addition, most EJBs and model beans have validation rules
  internally that prevent them from accepting semantically invalid
  data.  Such rules would prevent you from accomplishing the
  primary purpose of an ActionForm -- storing all of the user's
  input fields, so that you can reproduce the input screen.

* Also, if your form is multiple pages and you were using the real
  EJB, let's say you start updating properties based on receiving
  the first page.  Now, you've potentially started locking resources
  in the underlying database -- and you have to deal with the fact
  that the user may never come back and finish this transaction.

So, my bottom line recommendation is that you plan on building simple
JavaBeans
for your ActionForms.  Most of the time, an ActionForm will have just
getters
and setters, with no error checking (other than a validate() method if you
want
to use it, plus the reset() method).  PropertyUtils also has a convenience
function that can copy properties with like names from your EJB to the
ActionForm bean (or vice versa), to reduce the amount of tedious code that
this
approach implies.  And, at some future point, it's reasonable to expect a
development tool to be able to auto-generate ActionForm beans for you.

Using an EJB as a bean that provides data values used in the presentation,
on
the other hand, is pretty easy.  Just store the client-side instance you get
back from the EJB server as a request attribute or session attribute -- from
the
perspective of the Struts custom tags, this EJB just looks like a JavaBean
with
getter methods, so they don't care that it is really an EJB.  NOTE:  If the
EJBs
are really on a remote server this could have some performance impact -- you
might be better served to copy data into local beans in that case.

>
> Thanks,
>
> juan
>

Craig

Re: Design question

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Juan Gargiulo wrote:

> Craig,
>
> Thanks a lot for your answer.
> I think that I'm very close of defining the architecture for my application.
> Using action classes as adapters and session EJBs for business logic sounds
> good.

Yep.

> Also using EJBs as actionforms is a good idea because they are a good
> target for object reuse. But it is not clear to me how do this. I don't see
> how struts is going to know how to get one of this EJB-actionforms from the
> context. How I specify the name of the home for the EJB-form to the action
> class (to the struts descriptor)?
>

Actually, I do *not* believe it is a good idea to re-use an EJB as an
ActionForm.  In fact, this will be somewhat more difficult in 1.0, now that
ActionForm is a class rather than an interface.

The reasoning behind my belief goes like this:

* An ActionForm is part of the view layer of MVC, not the model
  layer like an EJB (or a regular JavaBean that represents
  persistent data).

* The sole purpose of an ActionForm is to maintain the state of
  all the input variables on a particular form, so that you can
  reproduce the form pre-filled-in if the user made an error that they
  need to fix.  This matches the expectations of users who are used
  to GUI-based client server apps, that never make you retype any
  input except the stuff you did wrong.

* Because of the above, the "domain" of an ActionForm does not
  necessarily match any existing EJBs or model layer JavaBeans.
  It is not uncommon to have inputs from a single form that will
  ultimately cause updates to more than one undelrying EJB or
  model bean.

* Using a separate class for the ActionForm means you can
  change the underlying organization of your model beans or EJBs
  without impacting the view layer (although there might be modest
  impacts on the Action classes that copy things back and forth).

* In addition, most EJBs and model beans have validation rules
  internally that prevent them from accepting semantically invalid
  data.  Such rules would prevent you from accomplishing the
  primary purpose of an ActionForm -- storing all of the user's
  input fields, so that you can reproduce the input screen.

* Also, if your form is multiple pages and you were using the real
  EJB, let's say you start updating properties based on receiving
  the first page.  Now, you've potentially started locking resources
  in the underlying database -- and you have to deal with the fact
  that the user may never come back and finish this transaction.

So, my bottom line recommendation is that you plan on building simple JavaBeans
for your ActionForms.  Most of the time, an ActionForm will have just getters
and setters, with no error checking (other than a validate() method if you want
to use it, plus the reset() method).  PropertyUtils also has a convenience
function that can copy properties with like names from your EJB to the
ActionForm bean (or vice versa), to reduce the amount of tedious code that this
approach implies.  And, at some future point, it's reasonable to expect a
development tool to be able to auto-generate ActionForm beans for you.

Using an EJB as a bean that provides data values used in the presentation, on
the other hand, is pretty easy.  Just store the client-side instance you get
back from the EJB server as a request attribute or session attribute -- from the
perspective of the Struts custom tags, this EJB just looks like a JavaBean with
getter methods, so they don't care that it is really an EJB.  NOTE:  If the EJBs
are really on a remote server this could have some performance impact -- you
might be better served to copy data into local beans in that case.

>
> Thanks,
>
> juan
>

Craig

RE: Design question

[Juan Gargiulo <ju...@mindstech.com>]

Craig,

Thanks a lot for your answer.
I think that I'm very close of defining the architecture for my application.
Using action classes as adapters and session EJBs for business logic sounds
good. Also using EJBs as actionforms is a good idea because they are a good
target for object reuse. But it is not clear to me how do this. I don't see
how struts is going to know how to get one of this EJB-actionforms from the
context. How I specify the name of the home for the EJB-form to the action
class (to the struts descriptor)?

Thanks,

juan

-----Original Message-----
From: Craig R. McClanahan [mailto:Craig.McClanahan@eng.sun.com]
Sent: Friday, November 10, 2000 12:18 PM
To: struts-user@jakarta.apache.org
Subject: Re: Design question


Juan Gargiulo wrote:

> Hi,
>
> I'm re-designing a web application that is mainly running with
> servlets/jsps/conn-pooling.
> I started using struts for prototypes, and I really like its architecture.
> The new design has to  be robust and scalable because we expect
considerable
> traffic. It is clear that the data tier should be implemented with entity
> beans, but I'm not sure yet about the web and business tier.
> One idea is to use struts (action classes+jsps+xml+xsl) to implement the
web
> tier, and java beans and session EJBs for the business tier. But I have
some
> questions for this architecture:
>
> 1. Is struts doing object pooling for action classes? (it's designed for
> high traffic?) If not, is there a way of doing this?

Struts uses one and only one instance of each action class.  As long as you
design your actions to be thread-safe (basically the same rule as for
servlets),
there is no need for more than one instance.

The most important rule is to not use instance variables in your action
classes,
unless you want to share information between requests.

>
> 2. Is it right for action classes to use session EJBs as business beans?
Is
> there any downside on this?

Using session EJBs makes a lot of sense as business beans.  The only caution
I
would have would be trying to use EJBs of either type as ActionForm beans --
you
should create separate classes for that purpose.

>
> 3. In the j2ee sample app. (the pet-store app.), Sun propose a design
based
> on events and handlers for controlling the page flow. Is struts a valid
> replacement for this?

The design of Pet Store is quite similar to Struts, although it uses a JSP
page
as the "front component" -- the role that is played by the controller
servlet in
Struts.

As time goes on, you will find that Struts and the Blueprints design (used
by
PetStore) will be getting closer together.  I'm in active cooperation with
the
Blueprints folks at Sun.

>
> 4. If combining struts with EJBs is fine, which is the best way of doing
it?

The two ways that make the most sense to me are:

* Encapsulate business logic in session EJBs.  Then, your
  Action classes become primarily "adapters" in design
  pattern parlance, translating input parameters from an HTTP
  request into corresponding property settings and method
  calls on the session bean.

* Use entity beans as the "model" beans you store as request
  attributes or session attributes, although you may have
  performance issues if the beans are actually remote -- it might
  be better to copy the relevant data you need for the presentation
  into regular JavaBeans that are local to the servlet container.

>
> Thanks in advance for sharing your knowledge.
>
> Juan Gargiulo

Craig McClanahan

Re: Design question

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Juan Gargiulo wrote:

> Hi,
>
> I'm re-designing a web application that is mainly running with
> servlets/jsps/conn-pooling.
> I started using struts for prototypes, and I really like its architecture.
> The new design has to  be robust and scalable because we expect considerable
> traffic. It is clear that the data tier should be implemented with entity
> beans, but I'm not sure yet about the web and business tier.
> One idea is to use struts (action classes+jsps+xml+xsl) to implement the web
> tier, and java beans and session EJBs for the business tier. But I have some
> questions for this architecture:
>
> 1. Is struts doing object pooling for action classes? (it's designed for
> high traffic?) If not, is there a way of doing this?

Struts uses one and only one instance of each action class.  As long as you
design your actions to be thread-safe (basically the same rule as for servlets),
there is no need for more than one instance.

The most important rule is to not use instance variables in your action classes,
unless you want to share information between requests.

>
> 2. Is it right for action classes to use session EJBs as business beans? Is
> there any downside on this?

Using session EJBs makes a lot of sense as business beans.  The only caution I
would have would be trying to use EJBs of either type as ActionForm beans -- you
should create separate classes for that purpose.

>
> 3. In the j2ee sample app. (the pet-store app.), Sun propose a design based
> on events and handlers for controlling the page flow. Is struts a valid
> replacement for this?

The design of Pet Store is quite similar to Struts, although it uses a JSP page
as the "front component" -- the role that is played by the controller servlet in
Struts.

As time goes on, you will find that Struts and the Blueprints design (used by
PetStore) will be getting closer together.  I'm in active cooperation with the
Blueprints folks at Sun.

>
> 4. If combining struts with EJBs is fine, which is the best way of doing it?

The two ways that make the most sense to me are:

* Encapsulate business logic in session EJBs.  Then, your
  Action classes become primarily "adapters" in design
  pattern parlance, translating input parameters from an HTTP
  request into corresponding property settings and method
  calls on the session bean.

* Use entity beans as the "model" beans you store as request
  attributes or session attributes, although you may have
  performance issues if the beans are actually remote -- it might
  be better to copy the relevant data you need for the presentation
  into regular JavaBeans that are local to the servlet container.

>
> Thanks in advance for sharing your knowledge.
>
> Juan Gargiulo

Craig McClanahan

Design question

[Juan Gargiulo <ju...@mindstech.com>]

Hi,

I'm re-designing a web application that is mainly running with
servlets/jsps/conn-pooling.
I started using struts for prototypes, and I really like its architecture.
The new design has to  be robust and scalable because we expect considerable
traffic. It is clear that the data tier should be implemented with entity
beans, but I'm not sure yet about the web and business tier.
One idea is to use struts (action classes+jsps+xml+xsl) to implement the web
tier, and java beans and session EJBs for the business tier. But I have some
questions for this architecture:


1. Is struts doing object pooling for action classes? (it's designed for
high traffic?) If not, is there a way of doing this?
2. Is it right for action classes to use session EJBs as business beans? Is
there any downside on this?
3. In the j2ee sample app. (the pet-store app.), Sun propose a design based
on events and handlers for controlling the page flow. Is struts a valid
replacement for this?
4. If combining struts with EJBs is fine, which is the best way of doing it?



Thanks in advance for sharing your knowledge.



Juan Gargiulo