Is a search card the only place you can put a search query?
Support Ticket
Is a search card the only place you can put a search query?+issues
Because my goal is this: Create a card that lists some static info and then lists results of a search. This would let me have a dynamically updating list of all the times a person is named in a particular plus card.
But if all searches have to be their own card first, I'd be adding a card to the site search results that's pretty useless to users just so I can make a card that's more useful to users.
Yes, search queries only work in search cards. I'm not quite sure I understand what you're hoping to do here. If you want to add static content that appears above the results when people enter their own search terms, we don't have a way to do that. But if you want static content above a search that is always the same (or based on who is logged in, using _user) that we can do.
Assuming the latter, you're running into a general Wagn pattern. A similar question we get is whether we would add a way to have captions on images. Rather than make the Image cardtype more complicated (or in your case, making non-Search cardtypes more complicated by somehow allowing them to process WQL, the Wagn-y solution is to use Wagn's inclusion power to build what you're wanting out of multiple cards. So for captioned images, I'd create a new cardtype that had a structure with a +image and a +caption. In your situation, I'd make two cards:
FIRST CARD
[Static info that is always here...]
{{SECOND CARD}}
The second card would be a Search card showing "all the times a person is named in a particular plus card." (which is part of what I didn't quite understand.
Hope this is helpful.
Yes, I know I can do it the second way. My concern is that means I'm creating a lot of junk cards that will show up in user searches just so I can construct something else out of them. Unless I can exclude a particular card from non-Admin search results? It's adding chaff.
The idea is this:
Every episode card I have has a +directed by card included. The name of the director is also a link. The link should take you to a card with some biographical data with a section that includes the search results for all +directed by cards that have his name, so you'd know which episodes he worked on.
you need virtual cards
Okay. That link doesn't describe how to make/use them. Is there a HowTo somewhere?
I don't have much time this weekend, but I added some preliminary content on the virtual card page.
Okay. I moved my questions to the discussion section there.
This probably doesn't go here, but in plain English, if I want my search to be: Return all cards which contain either a "directed by" or "written by" plus card containing the same name as this current, sorted alphabetically, and listed as links, can I do that? I think it's the OR part that I'm not sure how to do, because I think the rest should look like (with some missing brackets so maybe the text will appear as text):
"plus": "directed by", {"content": _self}, "sort": "name", "view": "link"
the "+directed by" cards should probably be [[Pointers]. if they are, you can do something like this:
{"right plus":["directed_by", {"refer_to":"_self"}], "sort":"name", "view":"link"}
What if they're not pointers?
The problem with using a pointer card is that in the labeled view, a pointer card doesn't have any separators between items, so names run together when they should have commas. But presumably if I actually add commas after each item, then the system will think the comma is part of the name of the card.
Ethan, in that construction, how would I specify looking in two plus cards at the same time? directed by and written by?
You can get a separator between pointer items with CSS, I forget the syntax for that right now but I know it's possible because I've done it in the past.
There is a trick that will let you look in two (but no more than two) plus cards, like so:
{"or": {"right plus":["directed_by", {"refer_to":"_self"}],
"plus":["written by", {"refer_to":"_self"}]
}
"sort":"name",
"view":"link"
}
No results? JSON::ParserError :: 757: unexpected token at '{"or": {"right plus":["directed_by", {"refer_to":"_self"}], "plus":["written by", {"refer_to":"_self"}] } "sort":"name", "view":"link" }' :: {"or": {"right plus":["directed_by", {"refer_to":"_self"}], "plus":["written by", {"refer_to":"_self"}] } "sort":"name", "view":"link" }
oops, "written by" should be "written_by"
1. the "refer_to" syntax can be used any time there are links / inclusions. doesn't have to be with pointers.
2. the css trick john mentioned: http://www.w3schools.com/cssref/pr_gen_content.asp
3. you could fix john's syntax with a comma between the '}' and '"sort"'
4. however, it's cleaner to do this:
{"right_plus":[
{"name":["in","directed_by","written_by"]},
{"refer_to":"_self"}
],
"sort":"name",
"view":"link"
}
(space in "written by" doesn't matter)
Still gives the same error even with that correction.
No results? JSON::ParserError :: 757: unexpected token at '{"or": {"right plus":["directed_by", {"refer_to":"_self"}], "plus":["written_by", {"refer_to":"_self"}] } "sort":"name", "view":"link" }' :: {"or": {"right plus":["directed_by", {"refer_to":"_self"}], "plus":["written_by", {"refer_to":"_self"}] } "sort":"name", "view":"link" }
:-P thx for finding my typo, and pointing out that usage of "in"!
I ended up just adding spaces between the pointer list links, which works well enough for readability. But I'll bookmark that CSS page in case I want to try again.
Hooray! Works. This feels very advanced. :-P Can "in" take any number of cards after it?
yes