A number of proposed/attempted applications take the form of editing and presenting sets of structured data. Examples include:
- Bibliography tools
- Lists of scenarios
- Unthreaded discussions
- Book or equipment databases
- Inquiry pages
These resemble the kinds of simple databases that could be built with HyperCard or with the WAFL tools that we have used for study participant tracking and bug lists.
Characteristics of these include:
- Sets of records, identifyable by name and/or number.
- Existing EODescriptor name/uniqueID should accomodate this
- Set of shared fields, available to renderings of all records
- Analogous to the background of a HyperCard stack or the %application associative array in WAFL
- Set of standard fields for each record
- Should allow a "field" to be any kind of shared object
- Should support (optional?) construction-on-demand of underlying replicated objects
- Could be an ordered list of (fld-name, template) pairs. A unique field id could be assigned to each to better support renaming of fields.
- Specification of a field to use as a sort key should be allowed.
- Ability to construct a template for interactive editor of fields associated with a single record
- Initially this could be accomplished by appending a size (height) field to the meta-data for each field and auto-generating a form-style table for each record.
- Eventually this would be a good candidate for delegation to a JavaScript
- Initial version could just make a JavaScript...
- Ability to construct an interactive UI for the database.
- This would essentially just be a mechanism for moving between records in the database.
- Initially this could just be done as selection of a set of standard choices: list, drop-down, tabs, name search
- Need to consider add/delete/rename/remove options
- Need to allow record presentation either from record name or from a field
- Ability to specify web presentation of a single record
- Need separate presentations for embedded vs single page?
- Could be done with standard swiki-style markup, though eventually we will want conditionals?
- Template would need to have access to shared (application) fields as well
- Also need access to record name and number?
- Ability to specify web editor for a single record
- Would need shorthand for "text field/area of this size" since we will need to embed original text state for merging
- Ability to specify application page
- Initially could be:
- Boilerplate text before list
- Option for sorting records by a field
- Template for entry for each record
- To allow list, table, full embedding, etc...
- Need a way to to parameterize record name and number
%NAME% and %NUMBER%?
- Eventually we would at least want conditionals here
- Boilerplate text after list
- Also need options for add/delete?
Roadmap:
- Initial version, targetted at use for a bibliography tool
- Editor for record schema: field-name, template, display-size
- Form builder for rendering UI for record
- Database UI that presents records in an ordered list and supports add/delete/rename
- Version 1.1, add web capabilities
Architecture notes:
- Does this kind of application (along with MOO, etc...) suggest that we need an alternate CVSource for UIs that are designed to be embedded, rather than presented in separate frames? This would be somewhat equivalent to what we currently do for web views, where servlets (generally) render standalone pages and WebViews (generally) render embedded content.
|