Communication Between DataParts

Caspio DataParts are powerful components that enable the display and manipulation of data within a modern user interface. Often, you may require multiple DataParts to communicate with one another to achieve seamless user interactions. For example, you might want to: 

• Use a Search Form to filter a report displaying a list of orders. 
• Show the details page of a selected order from the report. 
• Add a new note to an order selected from the list of orders. 

Each of these examples involves multiple DataParts (which can be placed on the same or different AppPages), and they need to exchange data between one another. Caspio offers a dedicated mechanism for passing these values between DataParts using DataPart fields, eliminating the need for query string parameters in URLs. 

DataPart Fields in Flex 

When you use DataParts on an AppPage, their field values are stored in the session of that page. This means: 

• Session Storage: Caspio automatically stores DataPart field values in database. 
• Session ID: The session is identified by a session ID, which is present in the URL of the AppPage. 
• Passing Data Between Pages: When a user triggers an action (like submitting a form or selecting a record) that redirects to another AppPage using the Go to AppPage option, the session ID is passed along, allowing the receiving AppPage to access the same DataPart fields. 

For instance: 

• A report DataPart on one page sends the selected record’s ID to another page displaying detailed information about that record. 
• A Search Form on one page sends the search criteria to another page to filter the displayed records. 

Handling Multiple DataParts on One AppPage 

If you have multiple DataParts on a single AppPage, and one DataPart needs to filter or interact with another, Caspio uses the same mechanism to pass DataPart fields between them. The session handles the communication between the DataParts, allowing for seamless interaction without exposing data in the URL.

Custom Links 

In some cases, you may want to use custom links (for example, links generated in an HTML block) instead of Caspio’s default redirection mechanism. In these scenarios, you will need to manually pass the session ID in the URL. To do this: 

1. Retrieve the session ID from the URL of the current AppPage using query string parameters. 
2. Append the session ID to the custom link.
   Example: https://yourcustomlink.com/appPage1?sid=[@query:sid] 

By passing the session ID this way, the new AppPage will have access to the DataPart fields from the previous page. 

Using DataPart Fields in Filters, Default Values, and HTML Blocks 

You can use DataPart fields in various components of your app, including: 

• Data Filters: Filter the records displayed based on values from other DataParts. 
• Default Values: Pre-fill form fields with values passed from another DataPart. 
• HTML Blocks: Dynamically display information or generate custom links using DataPart fields.

For examples of using DataPart fields in real-life scenarios, see Designing User-Friendly Navigation Between AppPages.

Session Expiration 

Each session lasts for 2 hours of inactivity. If no interaction occurs within 2 hours, the session expires, and any stored DataPart field values will no longer be accessible. If a user attempts to access a session after it has expired, they may encounter “No results found” messages, even if the records still exist in the database.

Cross-Domain Limitations 

DataPart fields can only be passed between pages hosted on the same domain. If, for example, your report DataPart is hosted on the default Caspio domain, but your details page is on your own website, you will need to revert to using query string parameters to pass data between the pages. 

Comparison: DataPart Fields vs. Query String Parameters

When to Use DataPart Fields vs. Query String Parameters 

Caspio’s DataPart fields are designed to simplify communication between DataParts without exposing sensitive data in the URL. However, for situations where sessions may expire or cross-domain limitations apply, query string parameters can still be a viable alternative.

A key scenario where query string parameters may be useful is when a single destination page is linked from multiple DataParts. For example: two lists of filtered records are on one AppPage, both linking to a record details page. When a user selects a record from the first list, views the details, and then returns to select a record from the second list, the details page might display both records. This occurs because the parameter from the first DataPart remains active. By using a query string parameter to filter the destination page, you ensure that only the selected record is shown.

By understanding the strengths and limitations of each method, you can choose the best approach for your specific application needs.