Ted Husted

Author
+ Follow
since Dec 02, 2002
Merit badge: grant badges
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Ted Husted

You can specify whether an ActionForm is placed in request or session scope. If you place it in session scope, you can just fill up the form a request at a time. If there is a corresponding parameter in the request, the property is populated. Otherwise it is ignored.
If you choose to use request scope, then each form must carry the properties forward using hidden fields.
Generally, I recommend using coarse-grained ActionForms with as many properties as you need for the application (or a group of related forms in a very large applications). This avoids having to maintain the same properties in multiple classes.
If you are using your own validations, you can subclass the base ActionForm and provide a validate for each distinct set of data.
If you are using the Struts validator, you can just define a formbean element for each distinct validation. The Validator doesn't look at the ActionForm class, but the form-bean name.
HTH, Ted.
21 years ago
Generally, you would just tuck that away in the application (or servlet) context under a predetermined name. The Struts tags (and Velocity View tools) will check all the scopes for any object referenced in a presentation page.
Within in an Action, you can access the object directly. The Controller servlet is provided as a member variable, so you have access to all the servlet methods.
In Struts 1.0, a helper servlet was often used to load such parameters (though you could also subclass the ActionServlet if you wanted). In Struts 1.1, there is a PlugIn interface for Actions, which you can use to load global resources like this.
HTH, Ted.
21 years ago
The ActionForwards defined in the struts-config are not recreated at runtime; the same instance is reused. Only the ActionForms are instantiated at runtime. Everything else is only instantiated once.

HTH, Ted.
[ December 06, 2002: Message edited by: Ted Husted ]
21 years ago
Generally, Struts applications should access any and all persistence layers through a facade accessed through an Action. The ActionForms bring the data up from the input forms, and the Action passes it through a facade to the persistence layer. Whether the persistence layer is a EJBs, CORBA, a web service, or plain old JDBC really doesn't matter.
For some EJB-specific advice see my Tip Use EJBs with Care.
HTH, Ted.
And I would also recommend taking a look at Middlegen before beginning a EJB project.
21 years ago
It's not clear what this has to do with Struts. The framework bundles a set of JSP tags that people find useful, but the tags are generally well behaved.
-Ted.
21 years ago
The struts-config file serves the same purpose as the properties file you describe. The elements in the struts-config are used to create "static" Java objects at start-up. The only object that is created again is the ActionForm, which are usually very simple JavaBeans. The design is really as efficient as it gets.
But, hey, do whatever works for you. Struts is an open source framework written by working developers. We aren't trying to sell you anything, we're just sharing what we are using ourselves.
HTH, Ted.
[ December 05, 2002: Message edited by: Ted Husted ]
21 years ago
Technically, there isn't a great deal of difference between a form button and link. The Struts html:link tag does accept dynamic parameters, either a single property or in a map. I can't be more specific without knowing more about the page you're working on.
HTH, Ted.
21 years ago
Craig McClanahan, who designed Struts, is also the implementation lead for JavaServer Faces. He is now working on a JSF version of the Struts taglibs to be released with the next JSF iteration.
For more, see About Struts and JSF.
Craig was also kind enough to provide the foreword to Struts in Action.
HTH, Ted.
21 years ago
The Struts bean and logic taglibs are generally useful JSP tags that people can use in JSPs instead of scriptlets.
Technically, you shouldn't need to use logic tags in a pure MVC application, but having a separate page for every possible state is usually not practical. Without any type of logic in a dynamic page, you can easily create the same type of maintenance issues that MVC is suppose to prevent.
The bean tags expose dynamic properties to the page. Without bean tags, or the equivalent, JSPs would not be useful as a presentation device.
The html tags create a bridge between the JSP and the Struts framework. These tags know where to find the framework objects so that the controller can interact with the view.
Struts generally follows the layers pattern. The view and controller can interact, and the controller and model can interact, but interation between the view and model is shunned.
Besides JSPs, another good presentation device for Struts is Velocity templates. The Velocity view tools can do everything the Struts tags do (and more!).
Migrating a simple application from JSP tags to Velocity templates is covered in chapter 17 of Struts in Action.
HTH, Ted.
21 years ago
Yes, if you are using the html:errors tag you should always define
errors.header=
and
errors.footer=
in your application resources file, even if they are blank.
HTH, Ted.
21 years ago
Generally this means that the class could not be instantiated for some reason. Take a very close look at the Tomcat logs to see if there are any clues there. Also be sure to read any error messages closely. Is it saying that it could create the class or couldn't find the class? Two very different circumstances. Also be very sure that the type names are given correctly in the struts-config. These properties are not checked until runtime, when the controller tries to create the objects.
HTH, Ted.
21 years ago
I believe the latest version of Macromedia's Dreamweaver may have better support for custom tags, including the Struts JSP tags, but I haven't had a chance to play with it much myself.
Often, you only really need to stub-out the ActionForms to go with the JSPs. An action mapping that just forwards from an input page to an output page is often sufficient for a preview. It can also be helpful to setup a mock Action that posts some preview data in the request, which you can then display on the JSP for testing.
Some people also find that page design can be easier with Velocity templages, since they are more forgiving than JSPs. Chapter 17 of Stuts in Action shows how to migrate a small application from JSP to Velocity
HTH, Ted.
21 years ago
People use all types of persistance layers with Struts: JDBC, JDO, EJB, OJB, CORBA, Torque, you name it.
But regardless of how you connect to a persistance layer, the best advice is to develop a facade (or internal API) for your application. The facade declares the inputs and outputs for each discrete function your application performs. Behind the facade, these input and outputs can connect to whatever you want. In front of the facade, a Struts Action can pass through the input (from an ActionForm) and then return the output (either in ActionForm or some type of collection or result object).
A facade also makes it easy to use more than one persistance layer. One method may use JDBC. Another method may use a search engine, like Lucene. A third may reach out to a web service. But they all look the same to whatever controller you want to use (including Struts).
The Artimus application bundled with Struts in Action uses this technique to connect to both JDBC and Lucene. Interally, we can switch from one to the other without the rest of the application knowing the difference.
A facade also makes it easy to switch between a working persitance layer and a mock persistance layer for unit testing.
HTH, Ted.
21 years ago
Generally, you should encapsulate whatever parameters your application uses in the ActionForm. So there would be a getParam1 and setParam1 property on the ActionForm related to this workflow.
Struts will then take care of populating the ActionForm from the request for you. This way you can deal with JavaBeans and pretty much ignore the request altogether.
Then in tags like html:hidden, you can just refer to property="param1".
An important design pattern to follow in Struts is to always link and submit to an action, never to a dynamic presentation page, like a JSP. This gives the controller a chance to populate any form associated with the request. In Struts 1.1, it also enables the module features.
HTH, Ted.
21 years ago
After getting together the top-level requirements, I generally start with a HTML click-through. At this point, it's a familiar medium for everyone and can be the simplest way to express what needs to be done.
It's then pretty easy to setup the ActionForms using the HTML click-through like a requirements document. Once you have the ActionForms, it's easy to migrate to a dynamic click-through using JSP or Velocity templates. Instead of Actions, you can use the forward property to send control out to the presentation page. At this point, you can also start validating data.
After that, it's a matter of inserting Actions that bring the click-through to life. Here, I may start with stub or mock actions that return the same static data from the click-through. This way I can test how the presentation pages will act when passed data from the controller.
Finally, when I run out other things to do, I break down and hook it up to the persistance layer.
So, yeah, what you're doing =:0)
This is the same general process covered in section 3.4 of the book.
HTH, Ted.
21 years ago