> > 2) Info vars in normal pages v.s. in info.* pages > > > They are all info vars and I think they are using the same BoltWire > > code to process. However, in a user's point of view, they are built by > > different method and locate in different place. At first time I read > > the docs about info vars, it confused me a while. > > They are all info vars regardless of where the are. And they can be > created anywhere using the same methods. The only thing unique about > the info hierarchy, is it can be written to using the info function, > but that is completely configurable. (See site.auth.info). What were > you thinking? >
If I want to set infocounter or infotags, I use [(info)] to do it, but if I want to write one info data just in current page, I just open it and write it by hand. No need to use [(info)]. Info data in a normal page is normal enough to look like normal text. They don't need further markup. So I was confused a little at first time reading the docs. Yes, Dan, I know you have already thought about these. I don't insist to change any term but explaining the difficulty when I was a newbie in learning BoltWire. Whether change the term or explain them more clearly is good for new comers. Cheers, linly On Mar 10, 1:23 am, The Editor <[email protected]> wrote: > I'm up for a bit today. Though no guarantee how long I'll be able to > tinker at the computer before tiring out. But thought I take a stab at > a couple things. > > First, one big problem with terminology changes is the docs have to > all be updated. Not always easy. Also, I notice most of your > comments Linly don't come with alternate suggestions. That's the other > hard part. But here are some specific responses: > > > 1) "Field" wiki v.s. data "field" > > I think using field => value for data and info vars is required. I > like fields for the various wiki's, mostly because it goes with the > barn/farm/field concept. We could call them "sites". But that doesn't > really mesh with the barn and farm idea. So I'm inclined to leave it > for now. > > > 2) Info vars in normal pages v.s. in info.* pages > > > They are all info vars and I think they are using the same BoltWire > > code to process. However, in a user's point of view, they are built by > > different method and locate in different place. At first time I read > > the docs about info vars, it confused me a while. > > They are all info vars regardless of where the are. And they can be > created anywhere using the same methods. The only thing unique about > the info hierarchy, is it can be written to using the info function, > but that is completely configurable. (See site.auth.info). What were > you thinking? > > > 3) "Footer" as zone page v.s. "footer" in site.snippets > > > Footer is a great design for coding BoltWire site, however, there is a > > snippet in site.snippets called "Footer" announcing the copyright > > message. How about rename it to "Copyright" or ...? > > Fair enough. That's easy to do. > > > 4) Stamp > > > The "stamp" folder containing the old version of pages which have been > > edited and set a timestamp on them. But they are not stamp itself. In > > my translation of BoltWire terms, it's very difficult to explain the > > term "stamp". I have to translate it to the meaning like: putting a > > timestamp on a page and archive it... > > > How about "cockloft" or "archive"? > > Cockloft? what is that? :) > > In English, the word stamp can also be use to suggest a copy. Like the > stamp of a big printing press to make a duplicate. Can't you translate > it that way? Rather than focusing on the timestamp, focus on the copy > aspect. We could I suppose call them undo's but I don't particularly > like that. Not to mention all the commands and functions etc. (and > docs) all refer to stamps. So I'd much prefer to leave that all alone. > One reason I like "stamp" was the play on both meanings. Stamping and > timestamp. > > > 5) Backup > > > Action.backup is not really backup but a tool to collecting pages for > > a plugin. It can be used to backup the whole pages folder obviously > > but it confuse me a while at first time I saw it. Using a backup file > > to install a plugin? Weird. How about "packing"? > > Yes, originally the idea was to do site backups, but I soon realized > it was not practical, though it could work for plugins. Anyway, it is > a backup of multiple pages and we use the restore command to extract > them. So backup and restore is accurate enough. Pack and unpack is > ok, good actually, but again I'm not sure the advantage is worth > reworking all the function names, actions, etc. (These should all > match). I'm inclined to leave this alone also. > > Others are welcome to chime in... If there is strong feeling for > changing some of these things we can tackle it. Esp if I can get help > updating the docs. > > Cheers, > Dan --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
