Page History

...

• When the user visits a find screen, if they have previously saved any searches then a drop-down input will be present in addition to the regular find form fields.
• If the user chooses not to use any of the saved searches but instead opts to use the find form as normal, then upon submission the find form will also present an option to save the search. This will be presented as a text input for the name of the search and a submit button. The save search option should only be presented when the user has submitted the form as normal and will not be present when the user has chosen a previous search from the drop-down.
• If the user selects a search from the drop-down instead of using the find form then the saved search will be performed and the find form will also be populated with the saved parameters
• If the user modifies a saved search by altering the form fields after performing the operation above then the user will be presented with the option of either saving the search as a new one or updating the existing saved search with the new parameters.

Implementation

Data Model

Two new entities will be required:
PersistedForm - Main entity

...

• The widget field will only be applicable for type="single" forms
• The persisted-form element will be a child of the form element (i.e. same level as the field element) and will use a subset of the field element attributes, i.e. the ones that make sense in this context for example the name attribute won't be present because the input names will be hard-coded.
• Only one persisted-form element will be allowed.
• Both load-form-drop-down and save-form-text will optional children of persisted-form, to be used only when you need to override the system defaults. So to add the feature to a form will generally be as simple as adding a <persisted-form/> tag.
• The persisted-form will perform in the following ways depending state of the _PERSISTED_FORM_ID_ parameter in the context:
  • _PERSISTED_FORM_ID_ is missing from the context - this means the form has yet to be submitted so the drop down list of persisted searches should be presented to the user. The list is retrieved by performing a lookup on the userLoginId and the form's target url.
  • _PERSISTED_FORM_ID_ is present in the context, but empty - The user has performed a search by the regular means and we should render the text input and submit button to allow them to name and save the search. In this instance there will be no hidden form but the on-submit event will alter the form's target to point to the common-controllers.xml saveForm request, the removed target will be inserted into the form as a hidden parameter and the entire form submitted to be saved. Using the form in situ (rather than an alternate hidden form) will allow the user to make adjustments to the search criteria before saving.
  • _PERSISTED_FORM_ID_+ is present from the context in the context and not empty - A saved search was requested so we should display the drop-down list with the current search selected. If for some reason the field contains an invalid value then we should treat it as empty and render the text box as above. The incoming context should also be checked against the persisted parameters to determine if the saved search has been modified and if so then provide options to either save the search as a new one (via a text-box and submit as above) or to update the saved search with the new parameters (drop-down with update link next to it).

We should be able to support the use of this feature within FreeMarker templates using a transform macro without too much trouble.

...

common-controller saveForm request, runs a service event that persists the search and then performs a request-redirect to the loadForm request (see below) with the newly created _PERSISTED_FORM_ID_ as a url parameter. If a _PERSISTED_FORM_ID_ is present in the incoming saveSearch parameters then the saved search represented by that id should be updated rather than creating a new one.

Loading the search

common-controller loadForm request, runs a java event that retrieves the form parameters based on _PERSISTED_FORM_ID_ and inserts them into the request attributes, then manually performs a "request" type response (using requestHandler.doRequest(...)) that targets the persistedForm.formTargetUrl. Basically performs a direct simulation of the persisted request except that the persisted parameters end up as request attributes rather than parameters.

...