Skip to content

Customizing Tizra forms

daviddurand edited this page Aug 23, 2012 · 3 revisions

##What you can customize I think these are the places you can freely replace tizra-generated forms:

  • username and password submission as done by the login form. (The operation of the target redirection parameters is expected to change at some point to reduce the chance of cross-site referral abuse, so don't depend on these).
  • Search and advanced search parameters as submitted by the two search blocks. You can use all values in these forms as they are generated by the system. Numerical values like the identifiers of collections can be used even though they are hidden from the user, but will obviously appear in the form regardless of publication status, visibility, and relevance in the way that the system-generated values are)

This list is a work in progress, so if you are replacing other system forms, please let us know, so that the list can be updated, or we can offer a risk estimate and/or an alternative approach to replacing the form.

##What you should not customize by replacing the Tizra form Not using the form blocks for these forms may create issues:

  • Account update form
  • contactUs form
  • all e-commerce forms
  • registration form
  • logout button
  • go to page "mini-form"

"Issues" could be anything from "works perfectly today, but might not work tomorrow", to "You'd probably never get it working properly even with weeks of effort".

In particular, Tizra forms may include any or all of the following:

  • user feedback. If a form block is not in place to process server feedback to the user (which is usually done on a field-by-field basis) the feedback will show up in a big ugly default error list at the bottom of the page.
  • pre-population of fields with values from the server (these may be from previous submissions or the result of queries in the Tizra databases). Not pre-populating fields may require users to rekey information from previous forms, or overwrite already saved data with the blank values.
  • hidden fields, which may: ** be mandatory or optional ** contain values that can only be correctly generated at the serve ** change status from mandatory to forbidden at any time. ** change content format or legal values at any time.

It is our job to make sure that we generate forms that will work when submitted to the server software that generated the forms, but except in a few cases, we cannot guarantee that any particular markup will work in perpetuity.

The need for this page was discovered in examining issue #98