Pagelet Development Guidelines

Follow these guidelines when developing new pagelets:

• Adhere to object naming standards.

• Do not provide any filter, sort, or refresh buttons because they also require trips to the application server.

• If you enable the cache homepage option in the web profile, the pagelet must be display-only and cannot be interactive.

Because the portal servlet performs page assembly and proxying only on blocks of HTML, a pagelet must:

• Be URL-accessible.

  The portal servlet will issue an HTTP request to the registered URL.

• Be HTML 4.0 compliant.

  The HTML returned will be combined with HTML from other pagelets to form the entire web page.

• Be sized appropriately.

  The pagelet's width should conform to the narrow or wide guidelines discussed in the Sizing section in this document.

  See Understanding Pagelet Wizard Display Sizes.

• Use JavaScript name spaces.

  If you write custom JavaScript code, ensure that JavaScript from multiple portlets can coexist on the same page. Only one namespace is shared by all portlets on a portal page. For example, if portlet A and portlet B both use the GETURL function, only one definition will exist for GETURL defined by the most recently processed portlet. If you need a different GETURL function for each portlet, then you must uniquely name the GETURL function for each portlet, for example, portlet A calls GETURL1 and portlet B calls GETURL2. If the same GETURL function is called by both portlets, then you don't need to rename GETURL because the most recent definition of GETURL will be used by both functions.

Pages created by way of PeopleSoft Pure Internet Architecture conform to these requirements. However, these requirements are not exclusive to PeopleSoft. As mentioned, pagelets can also be from remote, non-PeopleSoft systems, such as static HTML files or dynamically generated HTML from a variety of technologies such as JavaServer pages (JSPs), Java servlets, Microsoft active server pages (ASPs), Perl scripts, and CGI programs.