Base Class with universal logic for 'Shepherd Framework' (design and start of implementation): Difference between revisions

From OpenPetra Wiki
Jump to navigation Jump to search
Line 30: Line 30:
* UserControls that form the indiv. Shepherd Pages will need to be able to communicate with the Shepherd and be able to react on certain Events that the Shepherd might emit.
* UserControls that form the indiv. Shepherd Pages will need to be able to communicate with the Shepherd and be able to react on certain Events that the Shepherd might emit.
** These UserControls could be any UserControl within openPETRA, but it would need to implement a certain Interface (needs to be created)
** These UserControls could be any UserControl within openPETRA, but it would need to implement a certain Interface (needs to be created)
* Pop-up Dialogs from within the UserControls which form the indiv. pages need to be possible.
* Pop-up Dialogs (=Modal Windows) from within the UserControls which form the indiv. pages need to be possible.
** These Dialogs could be any Dialog Form (=Modal Window) within openPETRA, but it would need to implement a certain Interface (needs to be created)
** Data from those Dialogs needs to flow back to the UserControl, not to the DB directly as things are only committed at the end when the user presses 'Finish'!
** Data from those Dialogs needs to flow back to the UserControl, not to the DB directly as things are only committed at the end when the user presses 'Finish'!
** These Dialogs could be any Dialog Form within openPETRA, but it would need to implement a certain Interface (needs to be created)
*** to be able to communicate with the Shepherd (especially the data entered or the user's choice on something);
*** to be able to communicate with the Shepherd (especially the data entered or the user's choice on something);
*** so it knows it must not save data when pressing OK and to only hide itself and not close itself.
*** so it knows it must not save data when pressing OK and to only hide itself and not close itself.

Revision as of 15:21, 14 January 2011

Shepherds Framework Introduction

The Shepherds Framework will be a support in creating individual instances of 'Shepherds' for openPETRA. 'Shepherds' are Installer-like Dialogs with Next-Back-Finish buttons. They have several steps/pages and through that offer a 'guided walk' to the openPETRA user on what key data to enter (or review) for a specific purpose.

Example Screenshots of an existing PETRA (not openPETRA) Shepherd can be found here.


Base Class Purpose

TODO

Note: The corresponding Bug (=Feature Request) is Bug #206 (shared with the related Project Base Form for 'Shepherd Framework' (design and start of implementation)).


Desired Outcome

Key Requirements

  • The whole Shepherd will need to be specifiable through a YAML file
    • Title of the Shepherd
    • All the Shepherd's Pages
    • MAYBE: some way of defining 'Conditions' in a terse way for page transitions, etc.
    • possibly other things such as Size of the Shepherd Form...
  • Navigation Buttons and Navigation Panel need to be able to be change states dynamically at runtime
  • Finish Page
    • needs to have a MultiLine TextBox
    • needs to have an optional second MultiLine TextBox underneath the first one (needed in the 'Intranet Registration Shepherd'.
    • needs to have an optional CheckBox that allows to kick off another process/open another window/another dialog after data was successfully committed to the DB (needed in the 'Intranet Registration Shepherd'.
  • 'Sub-Shepherds' need to be possible
    • Realisation: specify all possible Shepherd Pages, incl. those of 'Sub-Shepherds' right away in the YAML file. Have the 'Sub-Shepherd' pages invisible initially and shown them once a 'Sub-Shepherd' is entered.
  • Ability to start off at an arbitrary page, which will become the 'first page'
    • This implies that when the user clicks 'Back' he can't go further back than this 'first page'!
  • UserControls that form the indiv. Shepherd Pages will need to be able to communicate with the Shepherd and be able to react on certain Events that the Shepherd might emit.
    • These UserControls could be any UserControl within openPETRA, but it would need to implement a certain Interface (needs to be created)
  • Pop-up Dialogs (=Modal Windows) from within the UserControls which form the indiv. pages need to be possible.
    • These Dialogs could be any Dialog Form (=Modal Window) within openPETRA, but it would need to implement a certain Interface (needs to be created)
    • Data from those Dialogs needs to flow back to the UserControl, not to the DB directly as things are only committed at the end when the user presses 'Finish'!
      • to be able to communicate with the Shepherd (especially the data entered or the user's choice on something);
      • so it knows it must not save data when pressing OK and to only hide itself and not close itself.
  • Navigation Panel on the left, collapsible
    • Show all available Shepherd Pages as a Collapsible Panel which hosts a Task List in 'vsShepherd' Visual Style.
      • Some Shepherd Page Task Items might be disabled - initially, or at run time.
      • Some Page Task Items might be hidden - initially, or at run time, or shown at run time.
  • Navigation Buttons 'Back' and 'Next' need to skip disabled and hidden Shepherd Pages when clicked!
  • Show 'Page x of y' in the Title of the Shepherd Form.
    • Note: 'y' can change dynamically at run time as Shepherd Pages can be hidden/shown at run time!
  • Some Shepherds will not only be used to enter new data, but also will need to be able to load existing data into the Shepherd.

Outline of the Solution

Step 1

Create a new Class in Project 'Ict.Petra.Client.CommonForms.Logic' (found in \csharp\ICT\Petra\Client\CommonForms\logic). Name of the Form Class File: 'PetraShepherdForm.cs' Name of the Form Class: 'TPetraShepherdFormLogic'

TODO


To Be Continued in Class...

TODO


Approval of Functionality and Program Code

TODO