CKAN: Ticket Query

#1525: [super] DGU package form refactor

icmurray — Tue, 06 Dec 2011 12:00:39 GMT

Form refactor. New create/edit package form wizard for DGU.

Etherpad: http://ckan.okfnpad.org/dgu-package-form

Tasks:

#1526 : Simple one-page form.
#1527 : Tab-ify the form using JS. No validation between steps.
#1541 : Setup server for the DGU form-refactor.
#1537 : Package create form wizard
#1538 : ~~Store partially-filled in package form data as a draft.~~
#1539 : ~~Package forms auto-save~~

How the rest of the work is carried out is up for discussion, as it depends on the approach taken. Whether to continue with validation using AJAX queries, or whether to break the form down into multi pages. Google doc outlining design(s)

#1537: Package create form wizard

icmurray — Thu, 08 Dec 2011 15:34:11 GMT

Create the form wizard for the package-new form.

Each section of the form will be a separate page as this was decided to be simpler than the alternative of making AJAX calls for validation at each stage. (*)

separate pages for each section of the form
validation carried out at each stage against the whole schema. Each section/page declares a list of schema keys that need to validate for that section to validate, and thus move onto the next section.
no draft saving to be performed in this ticket.

(*) - although the javascript alternative will probably provide better UX (each step would require a page-load in the wizard approach), it was decided that:

with the javascript approach it would be harder to test the workflow.
with the javascript approach there would be additional work displaying validation correctly. Although not that complicated, it was felt to add another point of failure.
the multi-page wizard is quicker and easier to implement, and if it provided poor UX, then the javascript approach would be used instead.
the multi-page wizard wouldn't preclude a javascript-tabbing create-form for other cases (where the wizard workflow wasn't such a good match, eg on the hedatahub.org)
the multi-page wizard wouldn't preclude a javascript-tabbing edit-form.

#1617: Update and test existing DGU package form : publisher / foi information

icmurray — Mon, 09 Jan 2012 10:03:04 GMT

[Child of #1526]

Contact/FOI information is derived from Publisher/User?, but can be altered for each dataset.

Original estimate: 4 days

Time spent: 0 days

Time remaining: 4 days

#1618: Update and test existing DGU package form : provide stubs for the theme and sub-themes

icmurray — Mon, 09 Jan 2012 10:05:57 GMT

[Child of #1526]

Provide the interface for the themes and subthemes hierarchy.

#1619: Update and test existing DGU package form : provide stubs for the publisher hierarchy

icmurray — Mon, 09 Jan 2012 10:07:52 GMT

[Child of #1526]

Create the interface used to retrieve publisher and authz information from the publisher hierarchy.

#1768: DGU: 7a. Public Publisher Dashboard (including QA Work and notifications) MUST PHASE 1

icmurray — Mon, 06 Feb 2012 14:49:00 GMT

#1538: Store partially-filled in package form data as a draft.

icmurray — Thu, 08 Dec 2011 15:47:01 GMT

Allow a user to save a partially-complete and probably invalid package-create form in order to come back to it later.

We decided on blob storage over a state field on the package:

prevents a history of the drafts being stored in the revision history. This is a particular problem if we start auto-saving, say every 20s.
the blob can store arbitrary extra data, such as how far through the wizard we are.

#1539: Package forms auto-save

icmurray — Thu, 08 Dec 2011 15:49:45 GMT

Using the saved-draft feature, we enable auto-save for the package-new and package-edit forms.

An AJAX call is made every N seconds, and the auto-saved blob is updated.

note - we don't want to overwrite a previously save draft, but we will want to overwrite the last autosave.