[MTOS-dev] Implementing new MT::App::Search

[Jay Allen]

On Thu, Feb 28, 2008 at 11:22 PM, Byrne Reese <byrne at sixapart.com> wrote:
>
>  Out of curiosity, could such an idea be implemented on top of this
> framework? Or must this be a core function?

It depends on how fast you want it to be and/or how flexible the base
class is about allowing manipulation of load terms/args.  That is, you
definitely DO NOT WANT to filter the returned results (slow).  Instead
you want to reduce the scope of the search via the query.

>  I like Jay's idea – my only concern is for the complexity of search keys
> and cutting and pasting them potentially into forms.

Okay, then, to eliminate all copying and pasting, you could
instantiate keys automatically when requested via the template tags
(realizing of course that you've just take security out of the hands
of the admins and put it into the hands of the designers).

To do this, you create a single tag: MTSearchKey.

Here's your documentation.
========

    MTSearchKey

    Returns the search key which represents the blogs in scope for
    the search.  With no attributes, the search key returned would
    allow for results from only the current blog.

    Attributes:

        * include_blogs - A list of comma-separated blog_ids to be
                          included in the search.  Alternately, the
                          value "all" can be used to return results
                          from all blogs.
        * exclude_blogs - A list of comma-separated blog_ids to be
                          excluded from the search.

    Example:

    The following specified a search for all blogs:

        <form method="post"
            action="<$MTCGIPath$><$MTSearchScript">">
          <input type="hidden" name="search-key"
            value="<$MTSearchKey include_blogs="all"$>" />
          <label for="search" accesskey="4">
            Search documentation:
          </label><br />
          <input id="search" name="search" size="20" value="" />
          <input type="submit" value="Search" />
        </form>

    The following change to the search-key hidden input parameter
    would limit the search to only blogs 1, 2 and 3:

        <input type="hidden" name="search-key"
            value="<$MTSearchKey include_blogs="1,2,3"$>" />

======

So, during the template build, the system would use the MTSearchKey
attributes to look up the search key and, if one does not exist,
create one.  That search key would then be output on the form.

The whole point here to is prevent blog readers from being able to
easily manipulate the search params to find hidden stuff which the
current system allows unless you essentially disallow ALL search from
protected blogs.

By the way, there are some people who still hate the idea of blog_id
being in the templates.  At times, I'm one of those, because users
don't care about blog IDs and they are nothing more than an annoyance
to template editors who have to keep a list of blogs and blog IDs
handy to make sure that their multiblog and search tags are correct.

On the other hand, I would say that the intersection between the group
of people who CARE about protecting certain blogs from search and that
of people who have mastered the art of copy/paste is pretty large,
percentage-wise.

>  Could multiblog be leveraged or extended to provide the same level of
> control over results I wonder?

Assuming you meant something like the above and not post-filtering
results, sure.

Jay