Versions Compared

Old Version 2

changes.mady.by.user Scott Gray

Saved on

compared with

New Version Current

changes.mady.by.user Jacques Le Roux

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

...

Previous discussions related to this topic can be found here:

  1. 2008-12-08 - http://n4.nabble.com/Save-Search-in-database-td196166.html#a196167Image Removed
  2. 2009-10-26 - http://n4.nabble.com/Searches-done-by-default-td213375.html#a221317Image Removed

User Interaction

...

Two new entities will be required:
PersistedForm - Main entity

  • persistedFormId - Sequenced primary key
  • formTargetUrl - Stores the target request (would be the target from the find form), this would be used to find persisted searches for populating the drop-down box and also as the target for persisted search submission
  • name - The user provided name for the saved search
  • persistanceType - This will mostly be a place holder for now, refer to potential uses below
  • userLoginId - The user for whom the search has been persisted, allowed to be null in the case of global saved searches i.e. available to anyone who would normally be able to view the formTargetUrl
  • createdByUserLoginId - means to keep track of who created a global saved search
  • createdDate - Timestamp for when the search was persisted
  • hitCount - Keeps track of number of times the persisted search has been used, could allow for floating the most commonly used searches to the top of the drop-down (not sure about this, just a thought)

PersistedFormParam - Child entity containing the request parameters for the request

  • persistedFormId - Primary and also Foreign Key to PersistedRequest
  • parameterName - The name of the parameter and also part of the Primary Key
  • parameterValue - The value of the named parameter

I'm not sure about the names but given the #Other potential uses of the entities, I've tried come up with something as generic as possible, the data could also be considered to represent a persisted request rather than a form. Other suggestions are welcome (smile)

...

  • 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 be 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).

...