You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Controller

(These rules will be replaced by those developed by the insideMIT Java-developers' peer group, once established.) 

  • It is the Action class' job to convert model data into a form that can be used by the View (if necessary).
  • Every Action that handles user input has a unique Action Form. Other views have request data only. Only data that is shared across multiple pages can be stored in session scope.
  • Action Forms should always be in Request scope (never in Session scope unless they are used across multiple pages as in a wizard).
  • When an Action's algorithm is dynamic based on user input, Action-chain patterns should be used, not helper-class patterns.
  • Actions must only perform one specific function and then either chain to another action or go to a JSP page.
  • User input can be validated for correct form, but not for business rules.
  • Actions do not return formatted view code (XHTML).
  • Collections must be documented to state what objects they contain and what properties those objects contain.

Model

(These rules will be replaced by those developed by the insideMIT Java-developers' peer group, once established.)

  • For SAP applications, proxy classes populated by SAP R/3 functions must be generated with the sap2java tool and not modified by hand.
  • For database applications, dao classes are responsible for retrieving model objects from the database using hibernate.
  • modelclasses are not specific to any front end or back end, but model the business itself. I.e. they do not represent the data for a page, nor do they contain proxy objects or make reference to the back end in any way.
  • service classes are responsible for converting proxy objects to model objects, and also for providing any business logic not already provided by the back end.
  • There must only be one service per application (not including mock services).
  • Collections must be documented to state what objects they contain and what properties those objects contain.

View

  • The application must adhere to look and feel rules specified in IDD's Information Architecture guidelines.
  • Java Server Pages
  • Tiles
  • Tag Libraries: Any or all tag libraries that come with current SourceLabs-licensed SASH Stack.

Controller

  • Struts (version-compliant with current SourceLabs-licensed SASH Stack)

Model

  • Spring (version-compliant with current SourceLabs-licensed SASH Stack)
  • JCo for SAP R/3 integration
  • Hibernate for data persistence and ORM (version-compliant with current SourceLabs-licensed SASH Stack)
  • No labels