我有兴趣了解人们将 Google Search Appliance 的搜索结果实施到现有网站的首选方法或方法。更具体地说，人们更喜欢如何将搜索结果实现/嵌入到他们现有的网站中，并在搜索结果周围保留周围的网站元素（菜单、会员资格等）。
据我所知，有 3 种不同的方法。
-
子域，处理子域中的所有内容
xslt – 创建一个完全由 google xslt 处理的 search.mysite.com，并在 xslt 中嵌入环绕站点组件。
-
使用 iframe 将搜索结果嵌入现有网站 – 使用现有网站，只需使用 iframe 将结果导入页面。
使用 iframe
-
通过使用服务器端处理将结果嵌入到现有站点中 – 这就是我之前使用定制开发和 GSALib 项目。
我很想听听是否有人有其他建议，以及人们是否从使用上述方法中受益或后悔。
I’m interested to hear peoples preferred methods or approaches to implementing the search results from a Google Search Appliance into an existing website. More specifically how do people prefer to implement/embed the search results into their existing site and persist the surrounding website elements (menus, membership etc) around the search results.
As far as I am aware there are 3 different approaches.
-
Sub-domain, handle everything in the
xslt – create a search.mysite.com which is completely handled by google xslt and embed surround site components in xslt.
-
Embed search results into existing site using an iframe – Use the existing website and just use an iframe to import results into page.
-
Embed results into existing site by using server side processing – This is how I have previously integrated search into a site using a combination of bespoke dev and the GSALib project.
I would be interested to hear if anyone has other suggestions, and were people have benefited or regretted using the above approaches.
发布评论
评论（1）
第一种和第三种方法是迄今为止我见过的最常见的方法。我定期与 GSA 合作，专门负责许多搜索界面的工作。实际上，我做了很多方法＃3，但我从未真正对一种实现或另一种实现感到遗憾 - 有些事情只能通过第三种方法来完成，所以如果你想要其中一种方法，那就是你想要的必须做的。可能还有其他考虑因素：作为顾问，我构建一些东西供其他人维护。我的客户是否会比 XSLT 更轻松地在当前环境中维护解决方案？大多数开发人员不太熟悉 XSLT。
我还看到了另一种变体 - 使用 XSLT 将 XML 重写为 HTML 或另一种 XML 格式，然后通过自定义服务器端应用程序使用它。我不太确定这样做的理由是什么，对我来说这似乎不必要地复杂，但这不是我的选择。
我还没有看到的另一种可能性是对设备前端使用 AJAX 调用，这可能会从前端返回 XML 或 JSON。
The first and third approaches are by far the most common I've seen. I work with the GSA regularly, and work on a lot of search interfaces specifically. I do a lot of approach #3 actually, but I've never really had regrets with one implementation or another - there are simply some things that can only be done through the third approach, so if you want one of those things that's what you have to do. There may be other considerations as well: as a consultant, I build things for others to maintain. Will my client have an easier time maintaining a solution in their current environment rather than XSLT? Most developers aren't especially comfortable with XSLT.
I've seen one other variation - using XSLT to rewrite XML into either HTML or another XML format, then consuming that through a custom server-side application. I'm not really sure what the justification for that was, it seemed unnecessarily complex to me, but it wasn't my choice.
One other possibility that I haven't seen yet is the use of AJAX calls to front ends on the appliance, which would presumably return XML or JSON from a front end.