is it advisable to use super.execute()?

Hi,

I have a common functioality(say Selecting a Date) which will be used across the JSP pages.I had created a seperate action form and action class to handle this functionality. Whenever i need to use this common functionality i will insert this tile into the JSP and my current action form and action class extends this common action form and common action class.

something like


is it good practice to call super.execute() method from the child class (from myAction in this case)?

Regards,
Ajay.

If this were my application, I don't think I'd go to the trouble of making a common Action superclass just to implement a few date routines.

I do like your idea of having a common date ActionForm from which to extend your ActionForm classes.

If all the date routines do is plug in some date information to the ActionForm, I'd just put these routines in a utility class. I'd create a Static method something like this:

DateUtils.pluginDates(commonDateForm);

Another solution I thought of since my earlier post would be to create dynamic getters in the CommonDateForm superclass. For example, if you just need to display today's date in a particular format, you could have the following method:

Rather than simply returning an attribute value, this method could calculate today's date and return a String with the date formatted how you want it.

This way you don't have to do anything at all in your Action class. As long as you have all your ActionForms extend from this common superclass, the dates will be available in all your JSPs.

Thanks Merrill,

But i do have a JSP page which contains only the above discussed date functionality. This required a ActionForm and Action class to be defined (which acts as base classes). Let me try to explain my scenarion more clearly

something like this


If any JSP page which will display the date option doesnt extend form commondateform it requires the same getter and setter methods to be rewritten in that class (which is not a best practice) and similarly the Action class has some generic code which needs to be executed when this generic functionality is used.

How do you suggest me to proceed in this scenario?

Thanks,
Ajay.

Thanks Meril,

And date is just a single instance i explained to you. There are some other scenarios which require database proecssings. for eg. The products provided by the specific company. it will be available in the database.


If i doesnt extends these classes, it requires me to rewrite this same code in the new classes. How do you suggest now?

Thanks,
Ajay.

I do believe it's a good idea to create a common superclass for your ActionForm. What I'm questioning is whether you really need to crate a common superclass for Action. I still believe if you look more closely at the problem, you will find a way to put all the logic necessary inside the getters (or possibly in the reset method) in your CommonDateForm superclass.

However, in the event that I'm wrong (What, me wrong? Impossible! ) and you do need to have a common Action superclass, the answer to your original question is that it's perfectly OK to call super.execute(). However, since the execute method returns an ActionForward, you will need to handle that. I'd suggest having your superclass execute method return null if everything is OK, and have it return an ActionForward only if there's some sort of error. In that case, here's what the logic in your subclass would look like:

[ December 15, 2006: Message edited by: Merrill Higginson ]

One thing to keep in mind is that Java only allows you to extend from one parent class. The idea of creating a CommonDateAction might sound good, so you try it for others: CommonProductAction and CommonUserAction. But then you hit a page that has Date, Product and User fields...but you can only extend one of you base classes. Java does allow you to implement many interfaces, so if you do go this approach be sure to work interfaces into your approach.

I don't really have an answer to your question (though I am not exactly sure what your question is). Reuse of tiles in Struts is not as clean as I would like it. Sure you can slap a tile on your JSP page, but I don't know of a way to populate that tile or save the results to the database with data without making code changes to the underlying action.

What common code would you envision going in a class such as CommonDateAction? I have several tiles that I reuse and it seems that most of the shared code is at the form level.

- Brent

As Brent pointed out, there are problems associated with using inheritance as a means of code reuse. The example you gave above is a perfect example. You need to inherit from DispatchAction in order to use it's functionality, yet you have some other functions you need to include, and you can't inherit from two classes.

Interfaces offer some definite advantages over inheritance, but one big disadvantage is that an Interface doesn't contain any code. It's simply a template telling what a class can do.

Another pattern for code reuse is known as "delegation". This simply means using another class to do your dirty work. To use the delegation pattern, you write a class that performs a particular function or set of functions, and then call methods on that class whenever you need those functions.

As I pointed out in my first post, one solution would be to put all the logic currently performed by your CommonDateAction superclass, and put them in a class called DateHelper or DateUtils or something like that. Then, if you need date related data placed in your action form, you simply call one of the methods on the class and pass it an instance of your action form to be populated.

Thanks Brent and Merrill,

I do understand the difficulty in inheritance. Lets say we try that using interfaces, i am planning to proceed it in the following way

1. Define an interface for each function which needs to be tiled.
2. Create a delegate method which peforms the functionality required.
3. Implement the interface in child classes and call the delegate to perform the action.

Is that right?


Thanks,
Ajay.

Sounds like you're headed in the right direction. The only question I have about your proposed solution is: Is it really necessary to use an interface in this case? An interface is generally used by other classes calling the class that implements the interface to tell what capabilities the class has. Since an Action class is only called by the Struts framework, and not by any other classes, I don't see that making it implement interfaces is of any value. Just provide the functionality in the delegate classes, and call the delegates from the Action class.

I agree. I would need to see more details before I said that you should start using interfaces, implementing delegate classes and such. An interface with the two methods, getDate and setDate is not that useful unless you have code that can generically processes your classes through the interface.

- Brent