You want to look at and create information in whatever way works for you, and Wagn lets you do that with many special URLs (web addresses) that take you exactly where you want to go, and show you just what you want to see.
Example
/Support_Ticket?view=new&_status=answered (see setting default content with links)
/Web_address_for_everything?view=edit
/Web_address_for_everything?view=history
/Web_address_for_everything+howto?layout=noside
/Web_address_for_everything+howto?layout=blank&view=raw
/Recipe+*type+by_name?item=open
/Image+*type+by_update?item=change
How To
To make links that create new cards of a specific types, replace "/cardname" with "/new/cardtype". Examples above also show setting default content with links.
The rest of these use the usual URL syntax for key/value pairs — the URL is followed by a question mark, and each key/value pair is expressed as "key=value", with an ampersand to separate each key/value pair (e.g. /wagn/Wagn_News?layout=noside&view=content) :
You can override the views of items in a Pointer or Search with "item=" and the name of the view you want to apply.
You can specify the type of a named card (if it doesn't exist yet, so that clicking on it offers to add it) with type=|card type|
You can specify the size of Image with "?size="
Tips
- The styling of internal and external links is different, and Wagn treats anything with a complete web address (beginning with http) as external.
- adding a "file extension" to a card's name can return a variety of file formats, for example: http://www.wagn.org/wagn/web_address_for_everything+Tips.txt
- You can override Wagn's special handling based on a file extension with "explicit_file=true"
- Cards can be referred to by their numerical ID as well as by a name (this is helpful sometimes when troubleshooting). On any page, you can find the main card's ID number by adding ?view=id. Once you have the ID, you can construct addresses such as "/~1031", "/~1031?view=edit", etc.
- Some of these can be powerfully combined by using nesting inside of links, especially with contextual names. (Note that you will want to use "core" views in such cases, to avoid unwanted HTML that otherwise goes before and after inclusions.) Also see contextual web addresses.
Discussion
Some of this will be changing. See RESTful Web API.
we need to get rid of this hideous card and make sure all the key points are covered in RESTful Web API or elsewhere.
"RESTful Web API" - just the name, and the way that page is now - seems likely to scare off some non-techies who are perfectly capable of constructing URLs. Are you okay with keeping a page like this, and if so what kinds of changes (to name and/or content) would you like to see?
Well, DRY doesn't mean we can't have multiple names for the same thing. We can just include the RESTful Web API stuff in a card with a less wonky name (but a wieldier name than this one).
I cleaned it up and corrected it so that it's not a huge liablility, but in general we want one canonical page for a given concept.
I'm fine with one page, just want it to be named, and content to start with, stuff that will be approachable by less-geekier folks.
What do you think of merging the two into a card simply named "web addresses" ? Start with the stuff telling non-geeks how to construct addresses, and later get into REST, POST, PUT, DELETE, etc.?
in REST terms, this page is really all about GET variants (it's about parameter options). I'm now thinking these should be two separate cards that refer to each other. It's ok that the RESTful one is in a bit more geekspeak; once you get into transforming with urls, it's good to know a little bit more...