Gee... David

Preserving Cross-Model Shared Variables in Portal.

Scenario

Assume you have a form into which the user enters multiple values.  Further, assume you want to manipulate these inputs on the server side, re-populate the inputs with the user’s values, and return the page to the user. This is a straightforward, common practice.

In a recent project I faced a similar scenario, with one complicating factor.  My implementation used inputs generated by builders in multiple factory models. To address the issue of sharing the values between the models I used Shared Variables.

If you are unfamiliar with Shared Variables they are a builder type that allows for developers to create variables using a Variable builder and then to share them across other models by ‘publishing’ them with a Shared Variable builder.

Initially my plan worked. I implemented the solution and then tested the design. In my case I frequently test applications as stand alone webapps. Later I deploy them as Portlets.  As I stated, the application performed as intended during initial testing.  I was able to submit my form, perform server side validation, and return the form to the user with inputs preserved.

It was later, when I deployed to Portal for testing, that I had an unwelcome surprise.  The tests that passed in the stand alone webapp failed on Portal.  Inputs were no longer being preserved during form processing.   My convenient technique did not work in the Portal context.

What happened and how could I preserve those inputs? This was especially important (an of course urgent!) as there were a number of interactions that occurred on the page, such that the form might be submitted for processing several times before the 'final' submit.

Solution

As it turns out there is a builder input in the Shared Variable builder that I overlooked.

As most of you know, there are often builder inputs located in an advanced inputs section. In this case there is one labeled “Use Outer Session”.  When configuring this builder the default scope is “Session”. Consequently the default value of the advanced option “Use Outer Session” is selected.

While I was investigating I learned from the help documentation that this choice means data is stored in the session scope managed by the Portal and not limited to the explicit portlet.  Could this mean that models in the project not associated with a Portlet Adapter builder are external to the portlet?

In any case, if the default value is changed such that the option is unchecked then the Shared Variable is not available to the various models.  In my case I may have “fiddled” (technical jargon for ‘examined’) with the scope with the consequence that the advanced option was changed.

Example

Now that we have examined my scenario in detail I would like to summarize the procedure. So, welcome to my developer’s kitchen and here is a new ‘recipe’ for ‘Input Preserves’. The ingredient list calls for a variable to hold the selection(s) and an assignment operation defined as a member of the action inputs listed in an action list builder.

In addition the usual ingredients for our web app include a page, various inputs such as a text input builder, a select builder, etc. We need to make an assignment to a Shared Variable whose underlying type is XML. We will then manipulate the values of this variable as needed by various models.

I prefer to centrally manage  my shared variables. In this example I might have several shared variables defined in a single model. First we create an XML typed variable and then we associate with a Shared Variable builder in which we use ‘Session’ scope and check the advanced option for ‘Use Outer Session’. If we named our variable builder “SelectedData” then we might name our Shared Variable builder something like SV_SelectedData.

Now that we have set up the variable we can move to a model that might set the value of a node in our shared variable. In another model, perhaps one that provides centralized management of various action lists, I have an assignment operation defined in an action list to persist the value. The action list input might look something like this:
Assignment!Variables/SelectedData/Values/CollectionName=${Arguments/CollName} This assignment access the variable “SelectedData” because it has been shared. We won’t see a reference to the shared variable builder. In addition you can see that we have an argument that might have been supplied by some HTML event handler such as a button on an on change event associated with an HTML select.

To complete the ‘picture’ we apply the value of a node in our “SelectedData” variable to the ‘Text’ input of a Text Input builder. The Text input might contain text such as this: ${Variables/SelectedData/Values/CollectionName}.

In this example we started with a variable in one model, stored a value in that variable in another model, and ‘consumed’ the value in a third model. The value will persist for the duration of the session since we used Session scope and is available to multiple models in the project because we selected the advanced option, “Use Outer Session”.

Bon appetite.

Comments (0)
David Wilkerson January 29th, 2008 12:15:08 PM