Gallery:嵌入:发展路线图
嵌入发展路线图[ ]
欢迎整合编写者参与此路线图的讨论，新点子的添加或对G2方案实现的协助。 我们需要协调并讨论特定的特点以确保结果能够对所有整合都有用。
请勿忘记在你在此页上的评论/部分之前添上你的用户名。
资料[ ]
valiant：如何开发新的整合。带有详细步骤和各方面阐释的指导。 目前的资料可被显著地改良，但它们只是一个开始。另外应编写一个有关整合 各方面的资料。
用户同步[ ]
valiant： google SoC项目（由 _dv负责）变为一个嵌入模块，它能够提供一个API来完成初始的用户同步。它还可周期性地被无法创建/更新用户hook/事件的整合所运行。
我们需要将此添加到G2官方存储库中，并可能会事先做些许更改。你已可以使用代码进行实验："嵌入"于gallery-contrib项目中的cvs模块。
被嵌入的外观主题支持[ ]
ozgreg： 此请求十分频繁，支持通过嵌入的呼叫进行Gallery2外观主题的设定。
站点管理面板[ ]
ozgreg： 通过嵌入的呼叫来提供一条途径呼叫/提取或链接到Gallery2站点管理面板，这样我们就可以扩展CMS了。
更多便捷功能[ ]
valiant： WPG2，joomla/G2，mediawiki等仍以各自非比寻常的嵌入理念和特色继续引人注目。但对于某些特点来说，需要过多的编码。我们需要尝试将这些特点安插回G2嵌入API或模块中。
ozgreg： 万分感谢Valiant对初始API代码所作的贡献和花费的精力。
目标：整合应能通过更少的代码和功夫就能提供这样的嵌入特点。
嵌入的相册/相片浏览器[ ]
valiant：嵌入的相册/相片浏览器à la mediawiki -> 选取图片（如为文章或blog进行的选取）。
ozgreg： WPG2 radar上的某种迷你浏览器，如果它是在G2中可通过API呼叫的模块的话，那么一切就会更加简单了。
eads： 这包含能够一键整合的javascript的特殊外观主题么？
valiant： 可能是特殊外观主题，也可能是特殊的模块页面或者是其他方法。以后就知道了。
capt_kirk： 我修改了Gallery2图片选取器（Image Chooser），这样它就不再需要TinyMCE。它仍作为TinyMCE插件运行，但你也可以呼叫它在任何浏览器中插入一个链接。这里有一个有关如何编写用于其他应用程序的javascript的演示。
更好的文章/博客支持[ ]
valiant： 对简化单个图片按名称，路径，id或相册选取/显示的强力支持。-> 在外部应用程序的blog/文章中显示图片/相册。参见mediawiki，wp，mambo，drupal…
ozgreg： WP利用作为概念运行良好的标记，我们一直遭遇的最大问题就是WP及其清理blog文章的有效途径。
菜单以及其他[ ]
valiant： Drupal，joomla...为G2相册等提供各自的菜单，比如通过外观主题变量进行收集。我们需要提供一个API或至少告诉用户如何去做。
验证通道[ ]
eads： 通过某常见的验证机制（比如HTTP验证）将你的G2站点封闭起来，但传送给G2来自呼叫app的正确验证信息。
valiant： 不确定你所需要的是否已实现。当G2被嵌入时，它将通过嵌入应用程序被访问。如果在嵌入应用程序中拒绝了到G2的访问，就无法访问G2了。另外，一旦G2被嵌入了，那么它将信任嵌入应用程序。当被嵌入时，G2不完成任何验证，而仅接受activeUserId。 关于apache / HTTP验证： 现在还不可能（将用户id由apache推送给G2），但是你可以通过保证由HTTP验证的嵌入应用程序的安全来拦截对G2的访问。
其他事项[ ]
valiant： 向G2 API端还能够传输其他的东西以减轻整合编写者的负担吗？
更多的图片区块选项[ ]
eads： 关闭图片区块中的链接功能。
eads： 定义尺寸并使它们能够在G2中自动被生成。 ozgreg： 我已对此问题提出了一个RFE -> 1256288。
批量同步[ ]
valiant： 扩展初始同步API以一批100为单位进行同步。如果你需要为某个庞大的（100k以上）用户库进行同步的话，最好一次进行较小批次的同步，然后刷新web浏览器为下一批做准备。由于我们的PHP/web服务器平台依赖的外部因素太多，我们就需要保证崩溃的可能性处于最低限度。
组同步API[ ]
valiant: 扩展初始同步API以支持组同步。 扩展初始同步API以支持组成员同步。
由于较之基础用户管理，组管理根据不同的外部应用程序而表现的不同，因此我们必须使其变得足够普遍/在同步代码中添加足够的可选变换。
简化整合[ ]
valiant: 完整整合方式是否应改变？如何使得复杂性得以隐藏？或者是否有哪些细节可以改进？
变量输入/输出字符编码[ ]
valiant: 目前我们使用UTF-8进行输出，而输入方式也希望使用UTF-8。UTF-8支持是对外部应用程序的严格要求。我们需要引入一个变量输入/输出字符编码处理。同时，我们保持内部处理的是纯UTF-8。
输入应当比较简单，因为我们已通过GalleryUtilities.class 运行了所有的HTTP输入。
输出就更困难了，因为没有所谓的输出过滤器。有些数据是来自数据库的，而有些则是生成的，还有的来自模板。最终所有的输出不是来自$gallery->translate （所有的模板 g->text也由此运行）就是来自数据库。因此问题就是：我们该如何处理数据库输出？当然就是分别对HTTP header();和<meta html头进行设定了。参见：在非UTF-8环境下运行Gallery2（g2）
“嵌入友好的”外观主题[ ]
valiant: 外观主题有关资料应该也提到了嵌入的外观主题以及选择对象。如css问题，相对字体尺寸，页面宽度，无边栏等。 也许tag（用户所提供的）外观主题也适用于嵌入的G2。
MichelleC: Bharat给的用于Drupal的外观主题去掉了边栏但强化了自动去除边栏的Gallery模块，因此没必要特地做一个外观主题。我更偏向这种方法。这样我们就无需应边栏而担心某外观主题是否合适了。不过它还需要做一些修正，因为边栏仍会显示在站点管理中。或许某种全局设定可以解决，如"if embedded=true then all sidebars=off"？
Kiz_0987: 我喜欢MichelleC的方法，那就是Drupal嵌入的工作方式—使用一个普通的Gallery2外观主题接着添加一个自定义的css文件覆盖那些会导致问题的元素。这样就使得可维护性变得更好了，比尝试由Matrix外观主题派生出某嵌入版本要好。然而，向gallerycss添加更多特征的方法会很有用，以防止出现嵌入应用程序影响gallery的问题。某些G2外观主题（如matrix）是很不错的，但某些则不然—对于模块css也一样。嵌入应用程序常常不具有css也正。我想是不是能有一种自动化的方式来达到此目的，而无需依赖外观主题/模块编写者。
针对所有整合的单个网站[ ]
dmolavi: Dariush Molavi创建了 EmbeddedGallery.com（目前直接连接到NukedGallery.net）作为Gallery嵌入支持单独的源。该网站会演化为类似OpenSourceCMS的网站，允许用户查看目前所有支持的CMS/门户/blog系统的整合样例。Shameless plug: 如果你是网页设计中而且希望能设计新的网站的话，请在NukedGallery.net上用短消息联系Dariush Molavi来获取更多相关信息。
整合管理器[ ]
valiant: 有一个独立G2模块或java小程序，它带有简短且颇具说明性的手把手指导来帮助你将G2嵌入到其他应用程序中去，这个想法很不错吧？我们要在所有整合中都引入某些标准化的方法，而这是可行的。 See: G2任务：整合管理器
非PHP应用程序及远程web服务器中的整合[ ]
valiant: 目前G2整入仅支持基于PHP的应用程序。一旦XMLRPC模块正式成为G2的一部分，我们就可以向XMLRPC接口暴露GalleryEmbed方法并允许整合整入任何类型的应用程序了；而它们甚至无需在同一个web服务器上。会话/cookie管理也必将很有前途。
eads: 你还可以使用XML/OPML feed来做一些简单的非PHP整合--这里feed的取回无需remote呼叫（除了HTTP GET请求）--将某个相册传入类似Dominey的SlideShowPro一样的应用程序中。
这将是一次壮举。目前网上还没有解决办法，而有了一不错的gallery like后端及XML输出能力，我们就可以使用slideshow pro或simpleviewer一样的应用程序了。其实现到底有多困难呢？最重要的就是要有一个用于查看的应用程序。Gallery已在幕后作出了很多，但这茬却要咱们先得弄出这种查看程序……
G2为主情况下的整合[ ]
valiant: 我们能够提供一个模块，它使得主仆关系中G2为主的情况下使得整合变得更简单，当然是G2与外部应用程序之间的整合。该模块会侦听GalleryEntity::save/delete事件（用户/组的创建/更新/删除），它还会提供一种插件结构，这样某个整合编写者只需编写1-2文件的G2模块就能够实现一些方法了：启动外部应用程序，创建/更新/删除外部用户。
Pbearne: 我希望此想法能够得到开发，因为很多网站开始都是相片相册，接着就发现需要更多额外的功能，比如联系方式及邮件互通一类的；其实也不需要完整的CMS但是还是想呈现出外观主题的情况就是如此。
eads: Pbearne，你可能都需要—你观点的一面就是，某些用户（包括我自己）希望能有一个开源的数据管理方案能够将这些或那些CMS整合起来，但自身不提供公共前端，而仅仅作为内部使用。
嵌入的又一不同方式[ ]
MichelleC: 正如其自身所表明的，G2是一个独立的应用程序，但是也能跟其他应用程序并用，但对其控制的越多效果会越好。就我的需求而言，我希望G2成为配角而让主要应用程序对其进行控制。其他人也许希望G2能够起主导作用。为了能够满足某种程度上的需求，我在此提出一些针对终端用户整合的函数。从G2为主导到caller为主导，各取所需。
DisplayGallery() – 这会将整个G2放入你的页面，同时带有http://www.plogger.org/docs/config/#integration的语句。
DisplayFullAlbumPage(ID) – 赋予其某个相册ID，就会显示整个G2页面，边栏及所有内容。
DisplayFullItemPage(ID) -赋予其某个相册ID，就会显示整个G2页面，边栏及所有内容。
GetAlbum(ID,Override) -赋予其某个相册ID，就会返回相册的主体，不带有边栏或头。
GetItem(ID,Override) – 同上
GetSidebar(ID) -赋予其某个相册ID ，就会显示应当显示出的边栏。
GetBreadCrumbs(ID) -同上
GetItemLinks(ID) – 返回一数组，带有缩略图，重设尺寸图片及全尺寸图片的链接。不返回HTML，仅是URL。
GetItemInfo(ID) – 返回一数组，带有有关该项目的信息，如是否为一个相册，可用尺寸是多少等。
GetNextItem(ID) – 返回相册中的下一个项目
GetPreviousItem(ID)
GetCustomFields(ID) – 返回某项目自定义字段的一数组。
... 还有很多函数同样能应你的需求将G2分解并植入主控应用程序中，这里只是一个开头。
如果头部已被发送则对cookies进行设定[ ]
phorum.org的嵌入模块很不错很有前途。
问题[ ]
嵌入往往意味着让另一应用程序的输出html出现在G2顶部。现在我们要求，一旦g2 handleRequest()被呼叫，emApp能够将输出仅处理一次，因为我们需要进行重新定向以及设定cookies等。
部分解决方案[ ]
对于重新定向没有一蹴而就的解决办法。
但对于cookies，phorum.org给出了不错的迂回措施：在g2输出的结尾或结尾某处加入<img src="main.php?g2_view=core.EmbedLogin&sessionId=..." border=0 widht=0 height=0/> ，接着每当站点载入时，浏览器就会向g2请求该图片的url。而用户就会在此不可见/“透明的”请求上获取cookie。 当然在此之前要在数据库中创建会话。