Opentaps Ajax Pagination Framework - Revision history

Sichen: /* Paginating in the FTL */

2008-01-29T20:15:51Z

‎Paginating in the FTL

Sichen: /* Configuring the Pagination Query */

2008-01-29T20:15:08Z

‎Configuring the Pagination Query

Sichen at 20:52, 21 November 2007

2007-11-21T20:52:27Z

Sichen at 17:24, 14 September 2007

2007-09-14T17:24:22Z

Sichen at 16:14, 29 August 2007

2007-08-29T16:14:23Z

Sichen at 16:13, 29 August 2007

2007-08-29T16:13:36Z

Sichen at 15:54, 29 August 2007

2007-08-29T15:54:05Z

Sichen at 00:50, 29 August 2007

2007-08-29T00:50:08Z

Sichen at 22:52, 28 August 2007

2007-08-28T22:52:18Z

Sichen: Protected "Opentaps Ajax Pagination Framework": Sysop page [edit=sysop:move=sysop]

2007-08-28T22:42:55Z

Protected "Opentaps Ajax Pagination Framework": Sysop page [edit=sysop:move=sysop]

@@ Line 98: / Line 98: @@
       </tr>
 </pre>
 Next, you would use the FTL <#list> directive to display the individual rows.  ''pageRows'' is returned from the pagination macro:

@@ Line 26: / Line 26: @@
 ==Configuring the Pagination Query==
-The second step is to configure the data for the pagination.  If you are doing a query or building a List of Maps or GenericValues, you do not need to do anything special: you can just pass your List directly to the paginator.  You can also define a query for the paginator  in a beanshell BSH script, which is typically used to retrieve data for display.  This would cause the paginator to do the query for you, rather than holding the entire of List of values in memory.
+The second step is to configure the data for the pagination.  If you are doing a query or building a List of Maps or GenericValues, you do not need to do anything special: you can just pass your List directly to the paginator.
-In most opentaps applications, the BSH script is used to do a lookup of data and then put the resulting list or list iterator (cursor) into the context for an FTL page or form widget XML to display, like this:
+You can also define a query for the paginator in a beanshell BSH script, which is typically used to retrieve data for display.  This would cause the paginator to do the query for you, rather than holding the entire of List of values in memory.  In most opentaps applications, the BSH script is used to do a lookup of data and then put the resulting list or list iterator (cursor) into the context for an FTL page or form widget XML to display, like this:
 <pre>

@@ Line 127: / Line 127: @@
 And that's it!
 ==Notes==
 If you use an EntityListBuilder, then add additional fields, you will not be able to sort by the fields which are not part of the database table.

@@ Line 26: / Line 26: @@
 ==Configuring the Pagination Query==
-The second step is to configure the data for the pagination.  We need to define what data we will be listing and paginating through in a beanshell BSH script, which is typically used to retrieve data for display.  In most opentaps applications, the BSH script is used to do a lookup of data and then put the resulting list or list iterator (cursor) into the context for an FTL page or form widget XML to display, like this:
+The second step is to configure the data for the pagination.  If you are doing a query or building a List of Maps or GenericValues, you do not need to do anything special: you can just pass your List directly to the paginator.  You can also define a query for the paginator  in a beanshell BSH script, which is typically used to retrieve data for display.  This would cause the paginator to do the query for you, rather than holding the entire of List of values in memory.
 <pre>
@@ Line 63: / Line 65: @@
 ==Paginating in the FTL==
-The pagination of the GL accounts will be handled in the file glAccounts.ftl, which previously only displayed a header.  The first thing we will need is to import the opentaps form macros:
+The pagination of the GL accounts will be handled in an FTL file like glAccounts.ftl, which previously only displayed a header.  The first thing we will need is to import the opentaps form macros:
     <@import location="component://opentaps-common/webapp/common/includes/lib/opentapsFormMacros.ftl"/>
-Then, we simply call the <@paginate> form macro with the function we passed in:
+Then, we simply call the <@paginate> form macro with the list we created in the BSH script:
     <@paginate name="glAccountOrganization" list=glAccountListBuilder>
@@ Line 125: / Line 130: @@
 ==Notes==
-Currently you cannot have variables which are not part of the query results be parsed inside of <@paginate>.  For example, you can use ${row} and ${row.glAccountId}, but you cannot show ${parameters.organizationPartyId} or something else from the context.
+If you use an EntityListBuilder, then add additional fields, you will not be able to sort by the fields which are not part of the database table.

@@ Line 116: / Line 116: @@
 Finally, you would wrap up like this:
 <pre>
    </table>
 </#noparse>
 </@paginate>

@@ Line 50: / Line 50: @@
 </pre>
-This function essentially defines what entity (GlAccountOrganizationAndClass) will be queried, what the conditions are in the ''where'' statement, and how the query results will be ordered.  The fields ''entityName'', ''where'', ''orderBy'', ''having'', ''fieldsToSelect'', and ''options' can be used to configure the query for pagination.  Then, '''you must make sure your function does this''':
+This function essentially defines what entity (GlAccountOrganizationAndClass) will be queried, what the conditions are in the ''where'' statement, and how the query results will be ordered.  The fields ''entityName'', ''where'', ''orderBy'', ''having'', ''fieldsToSelect'', and ''options' can be used to configure the query for pagination.  Note that orderBy here specifies the initial order by sequence.  In the pagination macro the user could define how he wants the fields ordered, and those will be saved the next time he visits the form.  Then, '''you must make sure your function does this''':
 <pre>
@@ Line 62: / Line 62: @@
 ==Paginating in the FTL==

@@ Line 1: / Line 1: @@
 In this guide, we will show you how to replace a static form-widget list form with an Ajax paginated form using the opentaps Form Macros pagination framework.
 The screen is the Financials > Configure >> Chart of Accounts screen and displays all the general ledger accounts configured for a company.  Originally, the list of accounts was created with the ofbiz form widget, but because a company typically has several hundred accounts associated with it, such a static form was not very user-friendly.  It always displayed 100 GL accounts per page, and paging through was slow.
-The first step is to edit screen widget XML definition and remove the references to the form widget.  Edit the file hot-deploy/financials/widget/financials/screens/ConfigurationScreens.xml and look for the screen "listGlAccounts".  You can remove the following lines which referenced the old form widget :
+==Configuring the Screen Widget==
 <pre>
@@ Line 19: / Line 23: @@
 These are no longer needed because they were used to control the pagination of the list of GL accounts from the server side, but the opentaps Ajax pagination form macro allows the user to set pagination choices.
-The second step is to set up the pagination list builder on the server side.

@@ Line 5: / Line 5: @@
 The first step is to edit screen widget XML definition and remove the references to the form widget.  Edit the file hot-deploy/financials/widget/financials/screens/ConfigurationScreens.xml and look for the screen "listGlAccounts".  You can remove the following lines which referenced the old form widget :
-<nowiki>
+<pre>
 <container style="screenlet-body">
      <include-form name="listGlAccounts" location="component://financials/widget/financials/forms/configuration/ConfigurationForms.xml"/>
 </container>
-</nowiki>
+</pre>
-You can also remove the lines:
+You can also remove these lines:
-<nowiki>
+<pre>
 <set field="viewIndex" from-field="parameters.VIEW_INDEX" type="Integer" default-value="0"/>
 <set field="viewSize" from-field="parameters.VIEW_SIZE" type="Integer" default-value="100"/>
-</nowiki>
+</pre>
 These are no longer needed because they were used to control the pagination of the list of GL accounts from the server side, but the opentaps Ajax pagination form macro allows the user to set pagination choices.
 The second step is to set up the pagination list builder on the server side.

← Older revision		Revision as of 22:52, 28 August 2007
Line 18:		Line 18:
	</nowiki>		</nowiki>
	These are no longer needed because they were used to control the pagination of the list of GL accounts from the server side, but the opentaps Ajax pagination form macro allows the user to set pagination choices.		These are no longer needed because they were used to control the pagination of the list of GL accounts from the server side, but the opentaps Ajax pagination form macro allows the user to set pagination choices.
		+
		+	The second step is to set up the pagination list builder on the server side.

← Older revision	Revision as of 22:42, 28 August 2007
(No difference)