atg dos and donts

3
ATG Coding Do’s and Don’ts 1. 99% of times do not try to resolve the component using Nuclues.resolveName (). All ATG Components used by an ATG Component (say A) should be defined in the configuration file of Component A. 2. If a class can be defined as an ATG Component define it. (Info objects need not be defined as ATG Components) Do not try to instantiate the class as you do in a general java project. Try to resolve from the nucleus. (For resolving from the nucleus refer to checklist no 1 defined above) 3. If you have an interface defined (say IntA) and you are using one of the implementation of this interface (ImplA) in your code (say CallerA) and the implementation itself is an ATG Component (CompImplA), do not have any direct reference to the implementation in your class (CallerA). You should refer only to the Interface (IntA) in your class (CallerA) and the implementation (ImplA) to be used should be defined in the configuration file of ATG Component (CallerA) as type CompImplA. 4. Do not try to get a jdbc connection using (DataSource) nucleus.resolveName ("/atg/dynamo/service/jdbc/JTDataSource"). Get the datasource from the corresponding repository Bestbuy might be creating different db schema for profile/commerce etc. In that case we do not have a single Datasource. So it’s better to get the Datasource from repository so that we need not change out code later. 5. On includes, use the page= parameter in all cases, unless you have a reason not to. This will give more predictable behavior. It let's you do relative or

Upload: sasivijayakumar

Post on 27-Nov-2014

246 views

Category:

Documents


4 download

TRANSCRIPT

Page 1: ATG Dos and Donts

ATG Coding Do’s and Don’ts

1. 99% of times do not try to resolve the component using Nuclues.resolveName (). All ATG Components used by an ATG Component (say A) should be defined in the configuration file of Component A.

2. If a class can be defined as an ATG Component define it. (Info objects need not be defined as ATG Components) Do not try to instantiate the class as you do in a general java project. Try to resolve from the nucleus. (For resolving from the nucleus refer to checklist no 1 defined above)

3. If you have an interface defined (say IntA) and you are using one of the implementation of this interface (ImplA) in your code (say CallerA) and the implementation itself is an ATG Component (CompImplA), do not have any direct reference to the implementation in your class (CallerA). You should refer only to the Interface (IntA) in your class (CallerA) and the implementation (ImplA) to be used should be defined in the configuration file of ATG Component (CallerA) as type CompImplA.

4. Do not try to get a jdbc connection using (DataSource) nucleus.resolveName ("/atg/dynamo/service/jdbc/JTDataSource").Get the datasource from the corresponding repository

Bestbuy might be creating different db schema for profile/commerce etc. In that case we do not have a single Datasource. So it’s better to get the Datasource from repository so that we need not change out code later.

5. On includes, use the page= parameter in all cases, unless you have a reason not to. This will give more predictable behavior. It let's you do relative or absolute path, using context-root for the J2EE app as the root. Using src has causes unpredictable behavior because it is meant to be used to access pages outside of the J2EE app. Always use the dsp:img tag and dsp:a tag

6. When you extend an implementation (B) of an interface (A) defined by ATG to add new methods to it, please create a new interface(C) that extends the ATG interface (A) with the required methods defined and your implementation (D) will extend B and implement A.

This will help you in adhering to point 3 incase if you face this scenario of extending a default implementation of an ATG Interface to add new public methods

7. Never attach an input form field directly to a property of a repository item.( Transaction issues will crop up if a form field is directly attached to a property of a repository item. ATG will call the setMethod first on the FormHandler and then call the handleMethod. All Transactions are started on handleMethod. But if

Page 2: ATG Dos and Donts

your setMethod sets the value in a repository it will happen on a separate transaction. We won’t be able to control it. )

8. Action of a form should be the URL of the same page. i.e Use `request.getRequestURI()` to populate the form action.

9. Forms should not span multiple page fragments.10. Direct Java in JSP should be avoided. Droplets and taglibraries should be made

use of.11. Use sendLocalRedirect() when redirecting to a page within the same domain. Do

not use sendRedirect() in such a case.12. Use of hashtables or java.lang.properties type of variables should be avoided in

pipeline servlets and droplets and other global components which are multi-threaded and also expected to run fast. Since hashtables are synchronized by default, they will become a performance bottleneck.

13. Use initial.properties to load all the global classes at Dynamo startup time14. A global scoped component should NEVER have a property that is session scoped

or request scoped.15. A session-scoped component should NEVER have a property that is request

scoped.16. If you are writing a huge formhandler, create a HashMap of properties and then

associate input fields in the JSP with the elements of the hash map. This way, you are creating a buffer between the repository item properties and the jsp input fields. In the handle method of the formhandler the different values of the hashmap should be retrieved, validated and should be dispatched to the repository or other destinations

Note: Working on strategy to facilitate Akamaization on all URLs. Will add that also to the checklist and send a note out.