clean up default search url

Idea

 

 

should be /*search?_q=<escaped term>

 

requires:

  • default view (content)
  • migrating variable name away from _keyword

 

 

 

I want to work towards a standard query that looks like this: /*search?term=whatever Let's look at the parts:

1. search -> *search. I think this is valuable, because *search is the card name. We're also switching to *recent

2. ? vs. /. In order to use the RESTful Web API, it really should be ?params. All the slash urls will be deprecated soon.

3. the utf8 is put there by rails to handle encoding weirdness in ie, but it really doesn't need to be there for GET forms like this one in which the data will never go into the db. I've coded around this.

4. _keyword= I think we should probably switch this to just term=; this will soon be easier; I've actually done a bunch of the coding for it but haven't yet merged it into the main develop branch yet. the value in having this versus nothing at all is that this is a pattern that will be generalized to searches with many variables

5. view=content. For now, I think this is going to have to be in the url.

 

More generally speaking, the great value in getting away from lots of custom special urls and using ONLY the simple patterns of our rest api is that we can move all of the design logic into our "pack system" and away from controllers. I'm going to be blogging somewhat extensively about the advantages of our new architecture over MVC, but for now the point is just that this is not a casual flip but part of a move to some very elegant reusable patterns.

  --Ethan McCutchen.....Sat Dec 24 12:43:25 -0800 2011


update:

 

for now it's going to be /*search?view=content&_keyword=<term>. I'm now thinking the short form of the final url should be /*search?content&term=<term> (though, of course, /*search?term=<term> would give open view).

  --Ethan McCutchen.....Sat Dec 24 14:24:30 -0800 2011


I get wanting a good REST API and thus for URLs with "?term=dog" to work, but is there any reason that shorter URLs with "*search/dog" couldn't also work? Is the tradeoff here between end users' simplicity re hacking URLs, and programmers' ease of discoverability re coding to the REST API?

 

imho short URLs are valuable enough to make it worth special-case coding to make content the default view for *search (or rather, whatever its codename is).

  --John Abbe.....Sat Dec 24 18:29:21 -0800 2011


For now, they can't also work because we don't want any custom behavior that can't be modularized, and we haven't built a modular way to create custom urls. We're getting rid of all custom url handling in the core, so the special stuff has to go until we've built a modular mechanism for it.

 

my take is that this is a case for the geeky sort who wants to tinker directly with urls but isn't a programmer. you are an important data point, of course, but not a very representative one in this regard :)

  --Ethan McCutchen.....Thu Jan 26 12:22:08 -0800 2012


Okay. add a modular mechanism for custom URLs

 

I started to add a note about this to Wagn 1.8+Upgrade Notes and the example I thought of was RSS feeds for searches, which seem to be broken now. Given a search http://www.wagn.org/search/interwiki the corresponding RSS feed was http://www.wagn.org/search/interwiki.rss but now we have http://test.dwagn.com/*search?view=content&_keyword=interwiki and http://test.dwagn.com/*search?view=content&_keyword=interwiki.rss gets a search for "interwiki.rss" and not the feed. So...ticket add new URL for feeds for searches?

  --John Abbe.....Thu Jan 26 19:18:03 -0800 2012


should work if you do *search.rss?...

  --Ethan McCutchen.....Thu Jan 26 19:21:31 -0800 2012


Nope. offers to download a file with some HTML in it. If there is a feed URL that works, the header HTML pointing to that corresponding URL needs to be coded back in.

  --John Abbe.....Thu Jan 26 19:22:52 -0800 2012


We had it before, as per http://philringnalda.com/rfc/draft-ietf-atompub-autodiscovery-01.html

  --John Abbe.....Thu Jan 26 19:25:39 -0800 2012


http://test.dwagn.com/*search.rss?_keyword=interwiki

  --Ethan McCutchen.....Thu Jan 26 19:50:38 -0800 2012


fixed that and the universal edit button link. thanks!

  --Ethan McCutchen.....Thu Jan 26 21:04:56 -0800 2012


I'm going to take off the 1.8 because I don't think we're going to change keyword to term or get rid of "content" yet.

  --Ethan McCutchen.....Fri Jan 27 08:18:42 -0800 2012


actually, the above is a good example of a flaw in the old interface: you can't search for "interwiki.rss". And that's part of why it broke so often. Note that google uses "q" for the query term, but that it doesn't give a simple url.

  --Ethan McCutchen.....Fri Jan 27 08:21:55 -0800 2012


I think I can live with RSS feeds not having a short URL.

  --John Abbe.....Sat Jan 28 12:25:16 -0800 2012


Re Google, obviously they don't care about RSS very much :-P (They're shutting down Google Reader July 1, and never did anything much interesting with it.)

  --John Abbe.....2013-03-21 22:51:10 +0000

+relevant user stories