"Since when do we separate data and logic?"

Since when do we put our business logic in our User Interface? Business logic doesn't belong in the action form OR the action.

>
> Since when do we put our business logic in our User Interface? Business logic doesn't belong in the action form OR the action.

You said "business," not me. ;)

Somewhere you have to map the form layer back
to the domain layer. If that happens in the
form code why is that worse than having a separate
action class? At least in the form you know where you
are so are using type specific calls from the start.
And as long as you are just mapping back to domain
objects you should be fine. Sort of like an anonymous
class that is used only as an adapter between
the gui and an application.

Somewhere you have to map the form layer back to the domain layer. If that happens in the form code why is that worse than having a separate action class?

I think that's a very fair point. However, my Action classes usually do more than just map the form into the domain. They embed errors and messages into the response, they decide which of the defined forwards to select depending on the output of the business process, and they sometimes need to dynamically construct their own ActionForwards.

All of these behaviors clearly belong in the domain of the controller, and so if you believe in the principles of the MVC architecture, then it makes sense to define the Action and the ActionForm classes separately.

If MVC isn't a big deal to you, then Bob's classes should be very helpful.

>
> If MVC isn't a big deal to you, then Bob's classes should be very helpful.

It is still MVC. The data in the action forms does *not* qualify as a model (I assume this is what you mean). ActionForms are simply data holders that transfer information from the view to the controller.

I can not reference it but I remember reading a post in the JSF forum(http://java.sun.com/j2ee/jsf) where Craig made an observation that when developing struts he made a mistake by not combining the form and the action similar to webwork, he did refer to webwork, in a way this has been rectified within JSF.

In fact, he started off the BOF saying that was one of his "mistakes" he learned from developing JSF, and I have to agree. The webwork way of using JavaBean setters in your action makes more sense and is less to maintain.

Philosophically, I think it's cleaner to keep the two components separate. I don't see Action classes as reusable components, but instead more of a placeholder for validation and navigation rules. Form Beans, on the other hand, could easily be reused by multiple Actions involving similar data sets.

Maybe in practice, there are more cases where combining the Action class and the Form Bean results in more maintainable code. My experience has been that they are better left as seperate components.

Monte - I agree that philosophically, it makes sense to separate the Action and the FormBean, but in practice, I think it's a lot easier to combine the two, and that was the first thing I noticed when I switched from Struts to Webwork. With Struts, if I had a form that had 8 different commands associated with it, I'd need an ActionForm to hold my domain object along with 8 different Action classes, each which may only need to execute one or two lines of code. With Webwork, I make the domain object a JavaBean property of my Action and I have 8 different methods. I now have an Action with a collection of methods to represent the form controller as opposed to having a collection of Action classes. Both will work, but I think it's a lot less effort with Webwork.

Rob

> I don't see Action classes as reusable components, but instead more of
> a placeholder for validation and navigation rules. Form Beans, on the
> other hand, could easily be reused by multiple Actions involving similar
> data sets.

Perhaps a DispatchForm is up your alley. When you implement a POJO, do you put all of the fields into a separate bean or do you put them directly in the class?

>

It is not a problem, you can subclass Action to override validation and navigation rules.

> Maybe in practice, there are more cases where combining the Action class and the Form Bean results in more maintainable code. My experience has been that they are better left as seperate components.

After I have made some projects that based on the Struts, I thinhk that it is the best way if we keep separately Actions and Forms. With each Form, we can use by multi Actions. If two forms have some same attributes, we can use the inherit way to create form.

" was talking with Gavin King at TSS Symposium, and he mentioned that in his own Struts use, he had moved the logic from the action to the form and reused the same action type for all of his action mappings."

I did the same at start, but now is a little different. See:

I have one "Action" common for the entire application and a Form for each form. Each form is responsible to provide data to Struts (Strings) and also, provide me a corresponding Object Value converted from the object Struts(String).

The "Action" common works with a delegator to pass actions and the object value to a higher layer, like Save, Delete, Clear, Add, etc.

The "Action" common also works as the Front Controller turning it very easy to manage.

From my experience it was easier than the usual Form+Action for each form.

Well, I certainly think we (at the Xwork / WebWork2 project) appreciate the flattery in the form of imitation, but I would suggest those of you not stuck in a political mess like Bob take a look at the original, the real thing, WebWork2....

Agreed. Unfortunately there are a lot of political messes out there :-)

Very true, Jason. The problem is that many big companies don't want to use anything other than Struts, sometimes even Struts 1.0. You come as a consultant and you see all those glass boundaries around you. What's a developer to do? I'd say, adapt a PHB's favorite product to one that works (should I say, rocks). Dressing up is a corporate way. ;-)

Serge

Since when do we separate data and logic?

Since every one started using SLSB, or earlier. And Web Services? And Service-Oriented Architecture? What is the problem to separating data and logic (I guess you mean behavior)? IMHO in a stateless world (HTTP), the OO way of combining data and logic may not be the best approach.

>
> Since every one started using SLSB, or earlier. And Web Services? And Service-Oriented Architecture? What is the problem to separating data and logic (I guess you mean behavior)? IMHO in a stateless world (HTTP), the OO way of combining data and logic may not be the best approach.

AMEN!

IMHO, Struts is a great all-purpose framework. It has room to improve (basic form data typing, support for calling sub-flows, etc.), but the primary problem with Struts is the lack of simple configuration tools, causing developers to abuse it.

For example, the concept of the action class is to facilitate the navegation. Each action class needs to be registered in an XML file, along with the pages that class can potentially forward users to. When users are required to define and maintain the navegation by hand instead of using a graphical tool, it's very easy to lose sight of the benefits of this framework and begin to build a framework on top of the framework to try to make things simpler.

At most the action class should do simple data checking and determine which of the valid pages users are forwarded to. The rest of the logic should be offloaded to the business logic tier so that it can be reused as necessary. Once developers begin to put business logic in the action class, they begin to complain about reusability.

Also, the idea that you could build an entire application with a single Action class that serves as a dispatcher completely negates the primary benefits that Struts provides. That's effectively what the Action Controller already does. Instead of using an Action class as a dispatcher, why not use a servlet directly?

Hopefully, with industry support growing for Struts, we will begin to see all major IDEs support graphical configuration of the navigation between Actions, JSPs, and Form Beans. I think that this should help reduce the abuse of Struts.

It does beg the question, however, of why Struts is being chosen in the first place for a project if the project architects feel the need to alter its basic functionality. Is it an attempt to comply with a project requirement imposed on the technical staff by some buzzword manager or is it the project architects who feel that Struts is somehow more "open" or standard, but is too limited to use "as is"? Just curious.

> IMHO, Struts is a great all-purpose framework. It has room to improve (basic form data typing, support for calling sub-flows, etc.), but the primary problem with Struts is the lack of simple configuration tools, causing developers to abuse it.
>

This would not make it onto my first page of problems with Struts... IMHO if the configuration is that complicated then that's your problem.

>
> Since every one started using SLSB, or earlier. And Web Services? And Service-Oriented Architecture? What is the problem to separating data and logic (I guess you mean behavior)? IMHO in a stateless world (HTTP), the OO way of combining data and logic may not be the best approach.

Ugh. This is a common misconception. You should try to avoid letting patterns aimed at performance improvement (session facade, data transfer objects, etc.) seep into your domain logic. You still need your OO domain model, and your session facade should map to that just as your actions map to your session facade (or business delegates).

Please watch the interview with John Crupi--they spend a lot of time on this topic. http://theserverside.com/events/index.jsp

Please watch the interview with John Crupi--they spend a lot of time on this topic.

I did watch the interview as well as the one with Rod Johnson. They both were singing the same tune - you need a domain model, and objects without behavior, e.g., DTO's are bad. I guess what they were suggesting is that we should take business logic out of SLSB's and put them into POJO's. The next logical thing to come then is to get rid of EJB container all together, and use AOP or IoC container instead. Am I reading this correctly?

"I did watch the interview as well as the one with Rod Johnson. They both were singing the same tune - you need a domain model, and objects without behavior, e.g., DTO's are bad. I guess what they were suggesting is that we should take business logic out of SLSB's and put them into POJO's. The next logical thing to come then is to get rid of EJB container all together, and use AOP or IoC container instead. Am I reading this correctly?"

Not really. You can accomplish the same by moving your logic to entity beans (i.e. implement your domain objects using entity beans). You were never intended to have your logic in SLSBs in the first place.

The only problem is polymorphism (entity beans don't provide for this yet). You can accomplish it rather easily though by layering objects over your entity beans. I did this on my last project and documented it in my weblog:

http://crazybob.org/roller/page/crazybob/20030814

Another, less flexible approach was documented here on TSS:

http://www.theserverside.com/resources/article.jsp?l=TwoLevelDomainModel

OO really does better isolate changes, make code more reusable, etc. All of that OO design experience doesn't get thrown out the window just because we're building distributed systems. The issue is that OO doesn't play well across remote interfaces. The trick is to build your OO system and then wrap it sparingly with thin remote facades. The facades should contain nothing but adaption logic, and the adaption logic should be isolated to the facade, for example DTOs have no place in your domain model.

AOP does the same to a lesser extent. IoC is simply a way to construct components and manage their lifecycles. In a way, both can be thought of as lighter-weight generalizations of EJB. Both are fairly new, but the benefits in and out of a J2EE container are already clear.

>
> I did watch the interview as well as the one with Rod Johnson. They both were singing the same tune - you need a domain model, and objects without behavior, e.g., DTO's are bad. I guess what they were suggesting is that we should take business logic out of SLSB's and put them into POJO's. The next logical thing to come then is to get rid of EJB container all together, and use AOP or IoC container instead. Am I reading this correctly?


I'm going to go out on a limb and say "YES".

>
> I did watch the interview as well as the one with Rod Johnson. They both were singing the same tune - you need a domain model, and objects without behavior, e.g., DTO's are bad. I guess what they were suggesting is that we should take business logic out of SLSB's and put them into POJO's. The next logical thing to come then is to get rid of EJB container all together, and use AOP or IoC container instead. Am I reading this correctly?


I'm going to go out on a limb and say "YES".

I did watch the interview as well as the one with Rod Johnson. They both were singing the same tune - you need a domain model, and objects without behavior, e.g., DTO's are bad. I guess what they were suggesting is that we should take business logic out of SLSB's and put them into POJO's. The next logical thing to come then is to get rid of EJB container all together, and use AOP or IoC container instead. Am I reading this correctly?

You certainly can do this without EJB, with the AOP + IoC approach, and it works well in many apps. (I would say it's the best architecture for the majority of web apps, that don't really benefit from distribution.)

But having rich domain objects doesn't pose any problem for using SLSBs, so doesn't mean that you have to throw out EJB in general. You can use SLSBs in front of JDO or Hibernate or TopLink domain objects, for example. This way you use EJB services such as CMT. EJB != entity beans.

Regards,
Rod

>
> I did watch the interview as well as the one with Rod Johnson. They both were singing the same tune - you need a domain model, and objects without behavior, e.g., DTO's are bad. I guess what they were suggesting is that we should take business logic out of SLSB's and put them into POJO's. The next logical thing to come then is to get rid of EJB container all together, and use AOP or IoC container instead. Am I reading this correctly?


Yes, a lot of us never jumped on the EJB bandwagon and have been doing just fine without it for years..

As one of SAIF's developers, I agree to most of his points. SAIF was to be a proof of concept of how easy it was to add WebWork features to Struts. However, soon after we released 0.1, I learned about the struts-chain project that will hopefully be the core of Struts 2.0 and perhaps even useable somewhere in the Struts 1.x releases.

Struts chain is a Chain of Responsibility design pattern implementation for the Struts RequestProcessor, the class that determines how Struts processes a request. Struts-chain is the long-term solution to providing features like interceptors, new Action models, Servlet API-independence, etc. It basically decomposes Struts processes into a chain of commands strung together by an XML file, although it could just as well be configured by any other method. This allows the developer to easily extend Struts or cut out unneeded Struts functionality. The use of a Context object frees Struts from the Servlet API and will support (and already does in commons-chain) Portlet API, JSF, or any other context.

The code is in the Struts CVS under /contrib/struts-chain I invite everyone to take a look and help get it up to production quality.

Don

Having used Struts scaffold code (I hope Ted Husted is listening ;-)), doesn't it provide the dispatcher mechanism. The worrying thing about the scaffold approach is that it prevents the usage of all those tools that enable you to graphically create actions/forms/forwards etc because they assume that you want to have separate action classes, and not a dispatcher. ?? any comments please.

The struts chain initiative is very encouraging

After a few struts-projects, I also had the feeling that struts (although recognized by me as a pioneer in the area) didn't go all the way in separating model view and controller.
So I very brief look at webwork2. When I saw configurations, I had 3 thoughts :
1) wouldn't it be simpler without configuration files. In my opinion, configuration files should be used where users of your software should be able to change things. The coupling between model-view-controller components is not something you want users to change so should therefor not be configurable.
2) The first impression of the documentation did not match with my understanding of mvc concepts.
3) Why duplicate all the html-tags in a mvc framework ? Seems like a waste of effort duplicating the html-tags. This way the users are forced to learn all the html-tags all over while they know the html-tags very good.

(I didn't yet do a webwork2 project so my thoughts must be interpreted that way)

So now I'm trying to build a new (open source) MVC framework as lightweight as possible. It has 5 simple interfaces (of which View and Controller are 2 of them) and doesn't use configuration files. It is in a very early stage so I only will give a pointer to people that ask me.
Current features :
 - easy to learn and use (5 interfaces)
 - supports easy separation of model,view and controller code in java-based dynamic websites
 - templates (@see the view-tag)
 - file-upload
 - messages and errors (including error-field-marking)
 - i18n
 - rebuilding a page without re-executing controller actions
 - detection of duplicate form submissions
 - ...

For the moment this is only a test to see if I can prove my point that mvc in the web-layer can made easier to implement and learn. If later it turns out to be good, I will release it open source.
If you want to take already a look at it, send me a mail. Feedback is welcome.

Regards,
Tom Baeyens
tom@jbpm.org

I thought the controller-interceptors are a nice idea so I just included them.
Regards, Tom.

> So I very brief look at webwork2. When I saw configurations, I had 3 thoughts :
> 1) wouldn't it be simpler without configuration files. In my opinion, configuration files should be used where users of your software should be able to change things. The coupling between model-view-controller components is not something you want users to change so should therefor not be configurable.


I'm not sure what you're talking about here. We map namespaces and action names to Action classes and parameterize the invocation thereof, including interceptors and results. These all need to be changeable by users.


> 2) The first impression of the documentation did not match with my understanding of mvc concepts.
> 3) Why duplicate all the html-tags in a mvc framework ? Seems like a waste of effort duplicating the html-tags. This way the users are forced to learn all the html-tags all over while they know the html-tags very good.
>


They are optional, and many don't use them. They merely provide convenience for showing field errors next to fields and laying out the input fields with templates. They also provide for evaluating the attribute values against the ValueStack, which can also be done with ww:property, but it gets more verbose.

> (I didn't yet do a webwork2 project so my thoughts must be interpreted that way)
>
> So now I'm trying to build a new (open source) MVC framework as lightweight as possible. It has 5 simple interfaces (of which View and Controller are 2 of them) and doesn't use configuration files. It is in a very early stage so I only will give a pointer to people that ask me.
> Current features :
> - easy to learn and use (5 interfaces)
> - supports easy separation of model,view and controller code in java-based dynamic websites
> - templates (@see the view-tag)
> - file-upload
> - messages and errors (including error-field-marking)
> - i18n
> - rebuilding a page without re-executing controller actions
> - detection of duplicate form submissions
> - ...

All of these are completed already in WebWork2 with a minimal set of interfaces and (IMHO) a very clean and well designed code base.

>
> For the moment this is only a test to see if I can prove my point that mvc in the web-layer can made easier to implement and learn. If later it turns out to be good, I will release it open source.
> If you want to take already a look at it, send me a mail. Feedback is welcome.
>
> Regards,
> Tom Baeyens
> tom@jbpm.org