[MTOS-dev] Supporting public/private search (was Implementing new MT::App::Search)

[Mark Carey]

On Sat, Mar 1, 2008 at 8:17 PM, Jay Allen <jay at endevver.com> wrote:
>  whereas, correct me if I'm wrong, you're suggesting enclosing the
>  entire form (and search results?) in a multiblog enabled tag:
>
>    <MTSearchContext include_blogs="1,2,3">

No, I am not quite suggesting this either.

I guess I am coming at this from the same angle as my Fast Search
plugin (right or wrong).  While it is a php plugin and has obvious
back-end differences, conceptually it works like this:

-check the URL parameters
-check the args for MTSearchResults
-rationalize between the two, and when conflicts exist, the args win
(prevents URL hacking)
-submit query and fetch results + counts
-template tags that rely of the results of said query *must* be used
only inside MTSearchResults (perhaps in the search header or footer).
-MTSearchString is a separate tag that is taken from the query
parameter, and can thus be used outside the results container (such as
in the <title> tag, etc.)

>  it sounds like we're in some agreement too.

Agreed.

>  So, if we require a
>  template parameter that would prevent abuse but even then, that means
>  that the search template has to be loaded *first* and then parsed for
>  the context.

Correct.  The blog context of the results (meaning the blog
*displaying* the results) might be set first, based the blog_id
parameter, but the rest, especially the search results, would not.
Performance-wise, is one approach better than the other (assuming the
same queries are being run)?  I guess this is the key difference
between the two approaches -- with search keys you have ability to run
the search query before loading the template, and with tag args you
have to wait until after loading the template...

-Mark