Opening caveat : this is just to explain where my brain went... not saying anything about what you should/shouldn't do, nor that you hadn't already thought of these things... You probably have! Just trying to present the whole picture of what I saw as the potential. Do with this as you will. =D Creating Imagining a table structure in a handout, you could get it there a few different ways. You could construct it elsewhere and paste it. You could construct it elsewhere and import it (though a parser you write). You could create in manually in the handout. You could create it through wizard-y queries where the API creates it. And then there are the hybrids. Obviously any solution where the data is preconstructed and then pasted/imported sort of renders this portion of the process moot, provided that everything gets into the handout properly formatted (ie, you can't have 3 header rows, Aaron. You just can't. So stop trying. It doesn't work like that. Because Julian said so!) To handle the ad hoc, in-game creation and maintenance of a new table, I'd some sort of brief wizard of interrogatives. API Command 1 =>
What is the name of your new table?
How many fields do you want to start with? Based on the answer to the second question, the API would then construct a new command line and assign it to a button in the chat interface, full of that many interrogatives for field names. The command line would also store the table name, so the script could pick that back up when the user clicked the button and answered the queries... API Command 2 => What is the name for field 1? What is the name for field 2? ...etc... If you wanted to get even funkier, you could allow for certain schema data to be associated with the fields -- either in a sibling table or in the first row of the primary table. For instance, the fields "Rarity" and "Realm" (below) have a limited list of entries they will accept: Item | Type | Rarity | Material | Cost | Realm -------------------|------------------|------------------|-----------|---------------------------------------
| | VR, R, N, C, VC | | | Destiny, Gardening, Astral, Elemental
-------------------|------------------|------------------|-----------|---------------------------------------
The Odetch | Hairpin | VR | Jade | 200 | Destiny
Secateurs of Might | Pruning Shears | R | Alloy | 50 | Gardening Once you had all of that, you can create the table. Presentation and Buttons You could have a handout button in the header row, to the right of the last column name, for "New Column"... which would ask for the name of the new field (and any associated schema data, if you were implementing that). Each row could have a "Delete" button in the same location in their row (at the end) to remove that item from the table... and/or one for "Edit" (if you needed to manage user interaction). At the top and bottom you could have an "Add Item" button, which would present the queries for the various field entries, reading the schema as necessary to turn a standard input into a drop-down of choices ("Rarity" would be read to have 5 options, "Realm" to have 4). In fact, the "Edit" line button is really the same thing, just prefilled with the data from the associated line. Querying/Reporting Let the user input their query, as you said, but then I would suggest a recursive descent parser to extract the field names and their comparison. I use something very analogous in APILogic... allowing for these comparisons: a = b // equals a != b // does not equal a > b // is greater than a >= b // is greater than or equal a < b // is less than a <= b // is less than or equal a ~ b // includes a !~ b // does not include ... and logical sugar... (...) // grouping && // logical AND || // logical OR That lets the user do things like: Material = Jade && Realm = Destiny && Cost <=300 The resulting entries could be output to chat in a nice interface with buttons that allow for actions on that item... you could have some pre-built button functionality the table-owner could choose to implement with this table... like "Acquire" (copy to the Speaker's character sheet) or "Edit" or "Delete" (if you're on the handout's access list). Meta Application Once you know the rules of architecture around how you'd store data (the rules that are behind all such tables derived from your script), you could write an access scriptlet as a meta-script to return a particular data point from the table based on a user's query input. If the script sees a particular syntax in the command line, it triggers a search to return the requested datapoint, and replaces all of that inline syntax with the data before the message is handed off to the intended-recipient script: !somescript --price|{& askjulian [Market Bazarre].[Price] Material=Jade && Realm=Destiny} Your meta-script would take everything in the {& askjulian ...} construction, and return the Price of the first item made from Jade that deals with Destiny magic from the table "Market Bazarre". By the time the recipient script (somescript) saw the message, the command line (contents) would read: !somescript --price|200 ... ...Not that I've thought about this a bunch, or anything. =D Like I said, old database guy, irked that there isn't a customizable, serializable data construct at the game level... specifically for things like inventories, treasure hordes, or whatever.