Portlet Development Best Practices and Coding Guidelines
Essential guidelines
Your portlet code must meet these minimum guidelines to ensure portlet quality.
A.1. Refrain from using instance variables.
A.2. Pass data to the view (JSP) as a bean in the request object.
A.7. Follow Struts design guidelines for Struts portlets.
B.1. JSPs should contain HTML fragments only.
B.2. Design view to fit on a page with other portlets.
B.4. Use portlet style classes instead of specific style-oriented attributes.
B.6. URIs, HTML element name attributes, and JavaScript resources must be namespace encoded.
D.1.Use portlet settings to store user-independent configuration data.
D.2. Use portlet data to store user-dependent configuration data.
D.3. Use servlet configuration for storing static initialization information for a portlet.
E.1. Limit the use of the portlet session for storing portlet state information.
E.2. Do not rely on portlet sessions if the portlet is to allow anonymous access.
E.3. Always request an existing portlet session.
E.4. Prevent temporary sessions from being generated in the JSP.
F.3. Use the preferred language of the requester to look up resource bundles.
G.2 Avoid the use the HttpSession to share data with other portlets/servlets.
H.1. For WML output, keep view between 4 and 5 decks.
I.1. Do not spawn threads.
I.2. Do not use threads to access J2EE resources.
I.4. Avoid synchronized methods.
I.5. Avoid long-running loops.
J.1. Use the Credential Vault to store sensitive data.
J.2. Be careful of what data is passed to the client.
K. For portlets that can be viewed offline:
. 1. Do not use PortletActions.
. 2. Specify explicit support for the PDA markup.
. 3. Avoid the use of potentially harmful action buttons.
. 4.a. Do not use cascading forms.
. 4.b. Avoid the use of dynamic lists of links.
L. Provide documentation for the administrator, including:
. 1. All context parameters and configuration parameters.
. 2. How the portlet uses caching.
. 3. Portlet session requirements.
. 4. Portlet messaging requirements.
. 5. The portlet’s use of the portal user profile.
Important guidelines
Your portlet code should meet these guidelines to ensure portlet quality. There might be circumstances where you would deviate from these guidelines for provide better erformance, reliability, or a better end user experience. In this case, you should document your justifications for deviating from these guidelines.
A.3. Use the portlet logging facility.
A.4. Adopt good code documentation habits.
A.5. Use the ContentAccessService to fetch external content, when necessary.
A.6. Cache portlet settings or portlet data.
B.5. Pages should be fully accessible.
B.7. Minimize dependencies on JavaScript.
B.8. Do not use pop-ups.
B.10. Use IFRAMEs with caution.
F.1. All portlet strings should be fetched from resource bundles.
F.2. All view JSPs should be language-independent.
F.4. Enable bi-directional support for text and images.
F.5. Organize portlet help files by language.
F.6. Be sensitive to cultural-specific formatting.
H.2. Fit the content to the device’s viewing area.
H.3. Eliminate unnecessary clutter.
I.3. Limit temporary storage.
I.6. Use JSPs instead of XML/XSLT.
I.7. Use caching as much as possible.
J.3. Enable single sign-on as appropriate.
Beneficial guidelines
Your portlet code would benefit from following these guidelines. However, they are not required.
B.3. Use Java style comments instead of HTML style.
B.9. Use taglibs whenever possible.
C.1. Make common functions available externally to portlets.
C.2. Combine portlets with similar functions into a single portlet with multiple
configuration settings.
G.1. Use portlet messaging to communicate (send messages) to other portlets on the
same page.
G.3. Use Click-to-Action to quickly enable inter-portlet communication.
H.4. Put links at the end of the document.
I have taken it from IBM. You can download complete document from here
Your portlet code must meet these minimum guidelines to ensure portlet quality.
A.1. Refrain from using instance variables.
A.2. Pass data to the view (JSP) as a bean in the request object.
A.7. Follow Struts design guidelines for Struts portlets.
B.1. JSPs should contain HTML fragments only.
B.2. Design view to fit on a page with other portlets.
B.4. Use portlet style classes instead of specific style-oriented attributes.
B.6. URIs, HTML element name attributes, and JavaScript resources must be namespace encoded.
D.1.Use portlet settings to store user-independent configuration data.
D.2. Use portlet data to store user-dependent configuration data.
D.3. Use servlet configuration for storing static initialization information for a portlet.
E.1. Limit the use of the portlet session for storing portlet state information.
E.2. Do not rely on portlet sessions if the portlet is to allow anonymous access.
E.3. Always request an existing portlet session.
E.4. Prevent temporary sessions from being generated in the JSP.
F.3. Use the preferred language of the requester to look up resource bundles.
G.2 Avoid the use the HttpSession to share data with other portlets/servlets.
H.1. For WML output, keep view between 4 and 5 decks.
I.1. Do not spawn threads.
I.2. Do not use threads to access J2EE resources.
I.4. Avoid synchronized methods.
I.5. Avoid long-running loops.
J.1. Use the Credential Vault to store sensitive data.
J.2. Be careful of what data is passed to the client.
K. For portlets that can be viewed offline:
. 1. Do not use PortletActions.
. 2. Specify explicit support for the PDA markup.
. 3. Avoid the use of potentially harmful action buttons.
. 4.a. Do not use cascading forms.
. 4.b. Avoid the use of dynamic lists of links.
L. Provide documentation for the administrator, including:
. 1. All context parameters and configuration parameters.
. 2. How the portlet uses caching.
. 3. Portlet session requirements.
. 4. Portlet messaging requirements.
. 5. The portlet’s use of the portal user profile.
Important guidelines
Your portlet code should meet these guidelines to ensure portlet quality. There might be circumstances where you would deviate from these guidelines for provide better erformance, reliability, or a better end user experience. In this case, you should document your justifications for deviating from these guidelines.
A.3. Use the portlet logging facility.
A.4. Adopt good code documentation habits.
A.5. Use the ContentAccessService to fetch external content, when necessary.
A.6. Cache portlet settings or portlet data.
B.5. Pages should be fully accessible.
B.7. Minimize dependencies on JavaScript.
B.8. Do not use pop-ups.
B.10. Use IFRAMEs with caution.
F.1. All portlet strings should be fetched from resource bundles.
F.2. All view JSPs should be language-independent.
F.4. Enable bi-directional support for text and images.
F.5. Organize portlet help files by language.
F.6. Be sensitive to cultural-specific formatting.
H.2. Fit the content to the device’s viewing area.
H.3. Eliminate unnecessary clutter.
I.3. Limit temporary storage.
I.6. Use JSPs instead of XML/XSLT.
I.7. Use caching as much as possible.
J.3. Enable single sign-on as appropriate.
Beneficial guidelines
Your portlet code would benefit from following these guidelines. However, they are not required.
B.3. Use Java style comments instead of HTML style.
B.9. Use taglibs whenever possible.
C.1. Make common functions available externally to portlets.
C.2. Combine portlets with similar functions into a single portlet with multiple
configuration settings.
G.1. Use portlet messaging to communicate (send messages) to other portlets on the
same page.
G.3. Use Click-to-Action to quickly enable inter-portlet communication.
H.4. Put links at the end of the document.
I have taken it from IBM. You can download complete document from here
Comments
Post a Comment