Re: FormBeans ... as an Interface.

["Struts-dev Newsgroup (@Basebeans.com)" <st...@basebeans.com>]

Subject: Re: FormBeans ... as an Interface.
From: "Vic C." <vi...@basebeans.com>
 ===
Vic C. wrote:
> OK so some people think I should preach FormBean as a View and not as a 
> Model, so here is ... why I do recommend FormBean as Model and you 
> should leave the door open.
> ( If you buy this 
> http://www.mail-archive.com/general%40jakarta.apache.org/msg03376.html 
> then you will like the rest )
> 
> Like I said, the cool thing about Bazaar vs Cathedral is that if a 
> better way is found, it is not a big deal to do it they "new" way. 
> FormBeans ... as an Interface is an old issue.
> 
> I used to do it the way documented: 2.6 Accessing Relational Databases
>  public ActionForward
>        perform(ActionMapping mapping,
>                ActionForm form,
>                HttpServletRequest request,
>                HttpServletResponse response)
> {
>  javax.sql.DataSource dataSource;
>  java.sql.Connection myConnection;
> 
>  try {
>    dataSource = servlet.findDataSource(null);
>    myConnection = dataSource.getConnection();
> 
>    //do what you wish with myConnection
>  } catch (SQLException sqle) {
>    getServlet().log("Connection.process", sqle);
>  } finally {
> 
>    //enclose this in a finally block to make
>    //sure the connection is closed
>    try {
>      myConnection.close();
>    } catch (SQLException e) {
>      getServlet().log("Connection.close", e);
>    }
>  }
> This implies JDBC in Action and in Model and in other places.
> http://www.mail-archive.com/struts-user@jakarta.apache.org/msg30193.html
> Or
> http://groups.yahoo.com/group/model_struts/message/48
> 
> 
> Clients are saying why should I do Struts when I can do ASP w/ ADO. When 
> they do "J2EE" they use the db tag and want to use the SQL tag so single 
> tier.
> They are not always cable do implement design patterns. They find them 
> complex. When they do a BO and a DTO and etc. they get lost.
> http://www.mail-archive.com/struts-user@jakarta.apache.org/msg30193.html 
> makes my case, it ends up a PetStore (since most of the paterns were 
> there to speed up slow EJB -
> Conculsion: The solution is in the middle, simpler than PetStore and MVC 
> and not single tier. This is the sweet spot.
> There are not roles and tiers or valid theory of re-use. MVC should be 
> presentation, application and data base, simple model 2.
> See struts source file doc folder model2.gif. There are no BO or DTO or VO or... Struts is an 
> alternative to PetStore.
> 
> 
> 2nd: People do not just do Struts. They do JSTL or bean:use.
> 
> 3rd: People use beans for Swing event notification, or for SOAP. 
> JavaBeans are great. And 2 JavaBeans are worse than one. With a single 
> JavaBean you only have to import Struts, no big deal.
> 
> 4th. You should be able to unit test the bean ( in a console) before you 
> use it.
> 
> 5th. Only simple things are practical. On a large project people get 
> lost in the woods.
> 
> 6th. Show me! There are no samples. WebPIM is a sample DB CRUD with 
> master detail on SourceForge. More sample coming. Like now do you master 
> detail on a single page updateable?  Show me the code, not PetStore
> 
> 7th. Corporate developers say they have 3 years of Java. More like 6 
> months. They can't do the complex design patterns. Developers of Struts 
> can.
> 
> 8th.  The point of design patterns and OO is productivity via reuse. 
> Some people do design patterns for the sake of doing a design patter, 
> and not for reuse.
> 
> 9th . I realize you design the engine. It just drives better this way in 
> the real world.
> 
> Summary:
> http://www.mail-archive.com/struts-user@jakarta.apache.org/msg30193.html 
> or db tags or.... A sweet spot in the middle.
> 
> 
> Also... DynaBeans violate some presentation, application and data base 
> clear separation principles. The view should not know much about data.
> Neither should the action.
> 
> Anyway, when client's hire me for a good practice, this is what I 
> recommend.
> Yes you can build the app the other way. The question is which will let 
> you finish faster, and which will be easier to maintain.
> 
> I urge you to keep the door open to an un predicted alternative.
> 
> 
> Vic
> 
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: FormBeans ... as an Interface.

[Ted Husted <hu...@apache.org>]

"Struts-dev Newsgroup (@Basebeans.com)" wrote:
> 
> Subject: Re: FormBeans ... as an Interface.
> From: "Vic C." <vi...@basebeans.com>
>  ===
> Vic C. wrote:
> > OK so some people think I should preach FormBean as a View and not as a
> > Model, so here is ... why I do recommend FormBean as Model and you
> > should leave the door open.

<snip/> 

Personally, I'd say that the ActionForms are controller. 

They capture the input from the view and pass it up to the model, which
is the classic definition of the controller layer. 

In Struts, the controller is a trinity: ActionForward, ActionForm,
ActionMapping. 

We talk about the ActionServlet as the controller, but it is really just
a static switchboard for these other objects, which are the programatic 
components of the Struts control layer. 

While I don't agree that ActionForm should be an interface, for all the 
usual reasons, I would agree that it can * implement * a business tier 
interface. Under some circumstances this can expand it's role from a 
view => controller DTO to a view => (controller) => model DTO. 

But the functional requirements of an ActionForm coupled with the 
design requirements of the JavaBean specification make this option 
available to a limited number of applications.

Happily, post 1.1, many of these issues will start to disappear since 
more and more developers will choose to use Maps to store formbean
properties or go with DynaBeans. We won't be rolling a bunch of custom
form bean classes anymore, the ActionForm will become transparent 
and not considered any more fuss than the ActionForward or 
ActionMapping.

But I think the most important thing to remember about Struts is that it
is primarily a way to integrate various technologies within a Web
application. There is no one right way to use all these technologies and
patterns, and so there will be no one right way to use Struts. Many
applications need to interact with other players in the enterprise, and
these interactions drive some of the design decisions. What is "best"
in one environment may not be "best" in another.

Meanwhile, I've just uploaded an update to the Artimus sample
application that demonstrates some of the design features mentioned
on the list lately. 

http://www.husted.com/struts/resources/artimus.zip



-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>