ATG Form Handler Best Practices Do's

-
  • Each and every JSP page should be associated with one form handler,it may be custom or OOTB form handler.
  • Avoid reusing custom formhandler; ideally it should be one to one mapping between page and custom formhandler.  This will reduce the maintenance effort and increase the readability.
  • Formhandler scope may be request or session, request scope is always recommended. Sometimes we can define session scope if the formhandler is called several times in one session, to avoid creation of multiple copies. But be very careful, you need to reset and initialize formhandler field after usage.
  • Formhandler should only refer to same scope or higher scope component i.e. session formhandler should never refer to any request scope component;session and global are valid scopes,and allowed.Never use Nucleus.resolveName to resolve component,this is very extremely expensive call. Better re-think about your component architecture.
  • Formhandler should never refer to another formhandler.  If they share form fields, better put those fields in base formhandler and then extend it. If this doesn’t solve well the purpose and makes your design complex, move common method to manager and refer it from formhandler to reuse code. ATG formhandlers are designed to be invoked from page. If you use it through component reference in other components, you may miss initialization beforeSet and afterSet callback methods.
  • All page data should be passed through formhandler, avoid passing any attribute through request and session.
  • Set the priority of the field to "-10" for required input fields other than submit button, so that it gets invoked after all of the setters have been called.
  • Return false from formhandler handler method if you are done with the page and no need to process the page further.
  • Return true to redirect to success page.
  • See ATG Repository Best Practices
  • See ATG Form Handler Basics 
  • See ATG Transaction Best Practice 
  • See ATG Weblogic Best Practices

Comments

Post a Comment

Popular posts from this blog

BCC site status inaccessible Agent Production in error state

-
Image
The Error Message showing in BCC T he error logs is showing the below message /atg/epub/DeploymentServer Failed to connect to agent 'Production'. This agent not allowed to be absent for  a deployment. The server will continue attempts to  intialize the connection. Set loggingDebug to true for  continued exception and stacktrace logging. Analysis This happens when the target/Production instance is down for some  reason or the RMI configuration which points to the target/Production instance may not be correct one. Fix If this is happening  due to target/Production instance down  then we can restart the target/Production Server,Other wise  correct the RMI configuration from the BCC agent configuration page and reinitialise. Verify the RMI Port in Configuration.properties file.Usually this file will be located in the path C:\ATG\ATG10.2\home\servers\ATGProduction\localconfig\atg\dynamo\Configuration.properties,make sure the
Read more

Weblogic Issues during EAR Deployment Exception in AppMerge flows progression

-
Unable to access the selected application Exception in AppMerge flows progression Bean already exists "weblogic.j2ee.descriptor.ModuleBeanImpl@..../Modules[weblogic.descriptor.internal.Descriptor.Beankey@....] This issue can happen in many scenarios, may be you need to check your deployment descriptors based on Application Servers used, this generally happens due to issue in XML files related to deployment. I got this issue when i mistakenly added the modules twice in the Manifest file, the module 'Store.Storefront' is added more than once in  'ATG-Required'  of my Manifest.MF file,due to this i am seeing the module 'storedocroot.war' is added twice in my application.xml which is located in the  path ATGProd.ear\META-INF\application.xml.Due to this i am not able to deploy my EAR file. I have removed the duplicate entry and deployed the application and everything working fine. ....... <module>         <web>             <web-uri>atg_
Read more

DUseSunHttpHandler=true weblogic.net.http.SOAPHttpsURLConnection Weblogic/Java HttpHandler issues

-
Verify the issue is happening due to the error throwing  from the weblogic class  SOAPHttpsURLConnection,then you need to inform the Application Server which handler implementation you need to use.  add the following option to JAVA_OPTIONS in   setDomainEnv.sh/setDomainEnv.cmd  on Unix/Windows.   -DUseSunHttpHandler=true.  eg:  set JAVA_PROPERTIES=%JAVA_PROPERTIES% %WLP_JAVA_PROPERTIES%  set JAVA_OPTIONS=%JAVA_OPTIONS% %JAVA_PROPERTIES% -  DUseSunHttpHandler=true -Dwlw.iterativeDev=%iterativeDevFlag% -  Dwlw.testConsole=%testConsoleFlag% -Dwlw.logErrorsToConsole=%  logErrorsToConsoleFlag%  This setting tells WebLogic to use the Sun's https Handler   implementation rather than the WebLogic one.  So after this,it will use the  class HttpsURLConnection from the  javax package.   See Also   SSL Handshake error   java.lang.RuntimePermission modifyThread
Read more