Stuart -- This sounds very intriguing.<div><br></div><div>Can you share some code or pseudocode? That would be very instructive.</div><div><br></div><div>Thanks!</div><div><br><br><div class="gmail_quote">On Wed, Jun 2, 2010 at 1:23 PM, Stuart Watt <span dir="ltr">&lt;<a href="mailto:swatt@infobal.com">swatt@infobal.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">


  

<div bgcolor="#ffffff" text="#000000">
Actually, I&#39;ll elaborate our more detailed solution.<br>
<br>
1. We don&#39;t actually use POST requests for search, but our GET requests
have many fields and strange Dojo magic<br>
2. We serialize the query with its many fields, using a bit of
compression on the URI query string, and base 64 encoding, into a
relatively opaque and relatively short token<br>
3. This string is used by our search request handler, which unpacks the
string and allows a pageable search by merging in a few additional
fields (_page and _page_size) which are not serialized (that was
underscore magic). Because the serialized/compressed search query token
is opaque and you can&#39;t have two searches with the same query token, we
use this as a cache key extensively for performance. <br>
<br>
We find this works well. Also, since we have a model object for the
search (with serialize/deserialize) we can create views on it which
allows us to generate nice textual descriptions of the search -- very
handy for user feedback. And our users like to keep a history using
these descriptions, so they can go back and look/run previous searches.<br>
<br>
The only problem would appear to be when the URLs become excessive for
a GET request. When this happens, the POST can handle the form,
generate the serialized/compressed search query bundle, and then hand
off to the GET request with that instead. <br>
<br>
One caveat we hit was Microsoft&#39;s IIS rejected path elements in URLs
which were more than 240 characters (bytes?) even the URL was sound. It
probably thought they might be files. So we did pass stuff as query
elements, as this seems to be more viable on Microsoft servers anyway. <br><div class="im">
<br>
--S<br>
<br>
<div><span style="color:rgb(102, 0, 0)">Stuart
Watt<br>
ARM Product Developer<br>
Information Balance</span></div>
<br>
On 6/2/2010 1:56 PM, <a href="mailto:will@serensoft.com" target="_blank">will@serensoft.com</a> wrote:
</div><blockquote type="cite"><div class="im">
  <div>Short version:</div>
  <div>
  <div><br>
  </div>
  <div>Using [% c.req.uri_with({ page =&gt; pager.next_page }) %] is
fine for a simple single-field search (where the form uses GET instead
of POST)... but how do we PAGE through (and/or cache) a multi-field
form search that uses POST?</div>
  <br>
  </div>
  </div><div class="im"><pre>_______________________________________________
List: <a href="mailto:Catalyst@lists.scsys.co.uk" target="_blank">Catalyst@lists.scsys.co.uk</a>
Listinfo: <a href="http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst" target="_blank">http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst</a>
Searchable archive: <a href="http://www.mail-archive.com/catalyst@lists.scsys.co.uk/" target="_blank">http://www.mail-archive.com/catalyst@lists.scsys.co.uk/</a>
Dev site: <a href="http://dev.catalyst.perl.org/" target="_blank">http://dev.catalyst.perl.org/</a>
  </pre>
</div></blockquote>
</div>

<br>_______________________________________________<br>
List: <a href="mailto:Catalyst@lists.scsys.co.uk">Catalyst@lists.scsys.co.uk</a><br>
Listinfo: <a href="http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst" target="_blank">http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst</a><br>
Searchable archive: <a href="http://www.mail-archive.com/catalyst@lists.scsys.co.uk/" target="_blank">http://www.mail-archive.com/catalyst@lists.scsys.co.uk/</a><br>
Dev site: <a href="http://dev.catalyst.perl.org/" target="_blank">http://dev.catalyst.perl.org/</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>will trillich<br>&quot;I think it would be worse to expect nothing than to be disappointed.&quot; -- Anne (with an &#39;e&#39;) Shirley<br>
</div>