> > OK. By the way, I see a little terminology problem: data field vs > > BoltWire field. In fact all "field" words are linked to the glossary.
> This is a legitimate point. Though I'm not sure how to fix it. All > variables are essentially field/value pairs, whether you are talking > about data, info, page, system, or skin vars. I don't think we could > call them anything else. Label? I think "field" is used in computing to describe both the label and the whole (label+data). In BoltWire it has a third meaning. In my opinion, "label" and "value" are the simpler options. "field" in "data field" is programmer's jargon, isn't it? > On the other hand we could perhaps change our notation for boltwire > fields. Perhaps calling them sites or wiki's. This is a very different "sites" is the easiest solution. No need to explain. And somehow it remains inside the metaphor. > Also, on the subject of metaphors, as I was thinking about the > solutions section, I found myself repeatedly thinking about PmWiki's > cookbook/recipe system. I really loved that, and never felt > the more clear our nomenclature, the easier and more precise our docs > will become. That's definitely something worth working on! I think the basic nomenclature needed for using BoltWire should be easily understood by non-programmers. If a metaphor is used, but it has to be explained everywhere, it's not useful. The current root metaphor (farm/barn) works fine, but I'm not sure if it can be grown and applied to the docs hierarchy. A "solution" is a "solution", no matter in a farm or in a kitchen :) Cheers, Marcos -- http://alinome.net --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "BoltWire" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/boltwire?hl=en -~----------~----~----~----~------~----~------~--~---
