Quick Browse

[laceysanderson]

The intent of this field is direct the user to a partially filtered search for more extensive browsing. In order to simplify the field, the design calls for a "Browse by [drop-down]". Based on what type of browser is selected from this drop-down, the user is given a tailored form.

[laceysanderson]

The admin would be able to configure

• the path the user is redirected to when the browse button is clicked
• the key to use in the url query string per type
• which form elements to use per type: list, checkboxes, radios
• auto-submit or show button

The "Add Browser Type" button adds an additional fieldset.

[laceysanderson]

Wireframes showing the types of forms:

[laceysanderson]

Decided to switch the browse field to pull options from a custom table/materialized view rather then hard-coding them. That way there is a lot more flexibility for options to vary per page.

[laceysanderson]

This has been started on branch 3-quick_browse :-)

[laceysanderson]

New design for storing of options

It was decided the original option storage plan was too intensive for admins. Furthermore, I came up with a table structure that I hope will work for most cases.

Two options will be supported by the module:

1. Options are constant for each field instance.
   • Options will be stored in trpfancy_browse_options
   • Options can be set when the field is first created and edited on any entity edit form
   • This option is less intensive for the administrator since options only need to be set once
   • Not always appropriate since if not all options are defined for all entities, your user
     might end up at an empty browser
2. Options will be specific to the entity/field instance combination.
   • Options will be stored in trpfancy_browse_options_per_entity
   • Options must be set on the entity edit form for each entity
   • What do we do if they're not set? Should we allow the admin to set a default on the
     field instance form? Should we not show the browse field?
   • More intensive for admins but ensures that the options are specific to the entity
   • Ideal for content types with few entities (e.g. organism)
   • Maybe allow this to be populated via a query to make it less intensive for admins?

[laceysanderson]

Decided not to create a UI for setting options at this time. The above tables (trpfancy_browse_options & trpfancy_browse_options_per_entity) exist and will be used. Admin are instructed on how to add options to the database manually.

Todo:

• support options in trpfancy_browse_options
• support entity-specific options in trpfancy_browse_options_per_entity
• if no option for a given entity, default to trpfancy_browse_options
• implement front-end design for the field
• show admin their current options on field edit page so they can verify they added them correctly.