I. motivation
I'd like to see more features in scoop that support integration with a well-structured set of data, around which discussion can focus.
Phantros' site 4literature.net is a good example -- there are all those texts that are being reviewed, so strong ties between stories and non-story data is important. Other uses include bookstore/library, a store or other catalog, or the tying of files (photos,sound,documents,diagrams), wikis, anything that can be considered an object.
Once this mechanism is implemented, there are plenty of fun possibilities, such as search enhancements, cross-referencing, and new types of stories...
For example, a story in the 'photos' section could automatically
display a thumbnail in the story_summary area, with a link to the photo that would be more reliable than a hypertext link.... i.e. you could change your site's directories around and the links would change automatically because they're not hard-coded in the story's text.
II. interface
With this feature installed, the submitstory page includes input fields for identifiers of objects that should be tied to a story.
III. db changes
A. a new table:
story_ties
----------
tie_id = auto increment primary key
sid
class = the name of a table like "books" or "wiki"
field = the name of field of that table
value = the value of the field for the record being tied to.
unique index on (sid,class,field,value)
<table>.<field> should be a key field, so that class+field+value identifies one and only one record in the scoop database.
tie_id is used to keep track of the order of insertion, so that you can list ties in order of relevance/strength.
B. a new block
story_ties_types block that is arranged table style (one record per line, values separated by commas), with fields:
----------------
class = name of the tied table
field = name of a key field in that table
label = what to call this object class being tied to
perm = name of scoop perm allowing creation of this tie type
max_ties = max number of ties of this type, per story
if this block doesn't exist, the patch to AdminStories.pm will have no noticeable effect.
C. perms
one or more perm(s) must be created that allow a submitter to enter story ties on the submit story page. One perm can be used for more than one tie type; i.e if you wanted you could have a perm "tie_stories" that controls the use all types of story types.
for each perm mentioned in story_ties_types block:
- add the perm name(s) to the "perms" block
- grant some group(s) the perm in the Groups admin tool
sample block contents
book,isbn,ISBN #,write_reviews,3
recipe,recipe_id,Recipe Number,1
patch,patchid,Scoop code patch,3
IV. TODO
- methods for displaying tied objects. currently you'd have to write your own box.
- search enhancements
- make the data entry more flexible, such as by addint a field to story_ties_types that controls input type (text field; select from list)
V. CODE
If anyone wants a diff now, that's cool. otherwise i'd like to do more testing and hear your ideas about this design.
VI. Using this feature for scoop.k5
Too bad we don't yet have wikis or some other form of versioned document objects on this site... wouldn't it be so useful to upload a piece code that you can continue to update? yet have it remain associated with a story that introduces it and maintains running commentary from all users? and be able to browse back and forward thru time -- from one draft to the next? and possibly allow other users to edit it, marked with different colors?
Using story_ties, we could not only tie this shared document that is held in the site's db, but also tie a link to the webCVS page. Then you can make diffs between any two versions of the cvs file and the discussed file... but i guess that's another sstory!
