Perhaps we could add a doc page on BoltWire terminology and address some of the issues you brought up. They were all excellent points and might be helpful to others as well. If I get some time, I may try and pull up a draft doc page later in the week. If you care to Linly, you are welcome to create it, and then announce it to the list and solicit feedback.
Cheers, Dan On Mon, Mar 9, 2009 at 8:37 PM, Linly <[email protected]> wrote: > >> > 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 -~----------~----~----~----~------~----~------~--~---
