Not idiots
Mar 25, 2011 (about 1 year ago)
Previously on corenominal.org:
Note, it has occurred to me that I could simply add an additional field to the ‘whird_content’ table for storing an array’s key-value pairs, which would then mean a user could have an unlimited number of extra fields to play with; however, I am holding off from doing this as I cannot think of a way of implementing it nicely without using some client-side scripting, which I have so far managed to avoid. If anyone finds my thinking cap, please let me know.
By “nicely”, I think I meant idiot proof, which was wrong. I know it is a huge generalisation, but, I do not think people/users are idiots. As a user myself, it kind of frustrates me when developers work to the lowest common denominator, aka the idiot, and I do not want to fall into the same trap whilst working with Whird.
So, I have gone ahead and implemented the new Whird feature. I decided to simply use a standard text area for creating custom key-value pairs for posts and pages — one per line, using a double-pipe as the delimiter. I have also started putting together some documentation for Whird, although I am struggling somewhat with how to index/categorise it. The document for the new feature is entitled, “Whird docs: view_data_extras” — catchy!
I have started using the feature myself, to conditionally include submenus for project pages. It seems to be working well and I am quite pleased with it — I think it makes Whird much more useful and opens up all sorts of possibilities.
In semi-related news, not so long ago, Becky and I attended parents’ evening at Emma’s school. We were chatting with Emma’s ICT teacher, who said, “Emma is a capable child, but she needs to fully read the class handouts before raising her hand”, which I translated as, “Emma is not an idiot, she just needs to RTFM!”
**chuckles**
4 responses to “Not idiots”
Add your comment
Use the form below to add your comment. Markdown syntax is available. Note, all comments are moderated.
Mar 25, 2011 (about 1 year ago)
Hey Core,
Having played with CouchDB and used SQL databases for some time I know exactly where you’re coming from. The CouchDB approach is to put the database entirely as key/value pairs, which works pretty well for the most part. All the data is returned as JSON which is nicely parsable by a lot of programming languages especially JavaScript. You could use that in your record instead.
Although the proper NF route is a one-to-many relationship of course ;)
Mar 25, 2011 (about 1 year ago)
@Matt, if I am honest, I have not really looked into CouchDB much. I keep hearing good things about it (I remember a certain Stuart Langridge on stage at LugRadio ‘09, exclaiming to the audience that they do not need SQL databases, if they have less than 8 gazillion records they should be using CouchDB), so I guess I should really. :)
Mar 26, 2011 (about 1 year ago)
no, i agree, anyone likely to be using Whird at this stage is likely not an idiot, though this statement is contradicted by the truly excellent way i hosed my initial install with an upgrade the other day… o_O
anyways, the point here was to say thank you for starting the documentation of whird. it’s tremendously helpful to review, and has given me some great ideas for expanding my theme.
reading the documentation, it seems the current setup for some of the values like the “hide_*” keys would be better used as boolean values as opposed to the isset approach. obviously this wouldn’t be right for the all of the extras, e.g. myopenid_username (AWESOME feature, btw!).
thanks for your continued development of whird, we “non idiots” appreciate it. :)
Mar 26, 2011 (about 1 year ago)
@nathan, you are right, the
hide_*keys are not ideal. I am thinking that the additional edit form inputs could have their visibility toggled with some client scripting, but I would prefer not to go down that route at the moment. I will give it some more thought. :)