CODEWITHSUNDEEP
javastruts2
MistyD
MistyD

Reputation: 17223

Organizing a Struts2 project (Which Packages)

Currently my project developed using simple JSP and servlets has the following packages

1-Business package (Contains summed up methods from service package under a business rule)
2-Service package  (Contains different services and their implementation - along with factory
                     method to call a specific implementation of each service)
3-Controller package (All the servlet controls ..)
3-Views              (All the jsps)
4-CustomTags         (Contain the Custom Tags)
5-Domain             (Contains Domain objects)

Now I am planning to implement the same project using struts2 could you tell me what packages should i introduce. I know the service and business package will remain intact what about the controller package ? Should i place all the actions in the controller package ? Any suggestion will be appreciated.

Upvotes: 0

Views: 129

Answers (2)

dsandrade
dsandrade

Reputation: 586

Is possible! Struts from 2.0 to 2.3.x (I used theses versions), if you use the annotations struts2-convention-plugin.jar dependency, you can do that:

enter image description here

The package default (generally is zx.yz.actions) mapped all Actions on the project and it is your package namespace from image above.

When you create a new package inner Actions package, zx.yz.actions.example for instance, you are creating a new namespace /servletContext/example in your application.

To disable it, you only need put a '/' before your "Action()" annotation method. For example:

    public class ExampleAction {

      @Action(value="/example", 
        @Result(name="ok", type="httpheader", params={"status", "200"})
      public String execute() {
      }
    }

The '/' in '/example', will put in de namespace default.

Upvotes: 0

mP.
mP.

Reputation: 18266

Do not organise all your classes based on their type, they should be organised or grouped together with their immediate collaborators. If you can help it, place XAction and XController together in the same package. Its silly to place XAction in a separate package with 49 other actions that really have no relation while its controller is somewhere else.

If you group collaborators together in the same package its quite easy to know the working group and be reasonably more confident that changing one probably affects the other. With your original suggestion, who really knows what Action works with what Controller and so on.

Upvotes: 2

Related Questions