Gallery:Embedding Development Roadmap
Embedding Development Roadmap[ ]
Integration authors are welcome to take part in the discussion of this roadmap, add their own ideas or even help implementing solutions in G2. We need to coordinate and discuss the specific features, to make sure that the resulting solutions are useful for all integrations.
Don't forget to add your username in front of your comments / sections on this page.
Documentation[ ]
valiant: How to develop a new integration. Explain all aspects and a step by step guide. The current docs could be improved considerably, but they are a start. Also, a general document about all aspects of integrations should be written.
User Synchronization[ ]
valiant: The google SoC project (by _dv) resulted in a embed module which provides an API to do the initial user synchronization. It can also be used to be run periodically by integrations that can't use create / update user hooks / events.
We need to add this to the official G2 repository and maybe change a few things before. You can already experiment with the code: cvs module "embed" in project gallery-contrib.
Embedded Theme Support[ ]
ozgreg: Pretty popular request this one, support setting of Gallery2 theme via embedded calls
Site Admin Panel[ ]
ozgreg: Provide a way to call/draw or link the Gallery2 site admin panel via embedded calls so we can extend the CMS
More convenience functions[ ]
valiant: WPG2, joomla/G2, mediawiki etc. continue to impress by means of fantastic embedding ideas and features. But for some of those features, too much coding is required. We need to try to port those features back to the G2 embedding API or to modules.
ozgreg: all thanks to you Valiant for the time and effort you spent in the initial API code..
Goal: Integrations should be able to offer such embedded features with much less code and with less work.
Embedded album / photo browser[ ]
valiant: Embedded album / photo browser à la mediawiki -> picking images, e.g. for articles / blogs.
ozgreg: some kind of mini browser on the WPG2 radar, it would make life a LOT easier if instead it was a module in G2 that I could call via API.
eads: Does this include special themes with javascript that will can do a one-click integration with an article/post?
valiant: Maybe with special themes, maybe by special module pages or by other means. We'll see.
capt_kirk: I've modified Gallery2 Image Chooser so that it no longer requires TinyMCE. It will still work as a TinyMCE plugin, but you can also call it to insert a link in any browser form. Here's a demo of how to write the javascript for using it from any application.
Better article / blogging support[ ]
valiant: Powerful support for simplifying picking / showing a single image by name, path, id, or an album etc. -> show images/ albums in blogs / articles of the external application. See mediawiki, wp, mambo, drupal, ...
ozgreg: WP utilises tags which as a concept works well, the biggest issue we continuous run into is WP and the way it is helpful in cleaning up blog entries :(
Menu's etc.[ ]
valiant: Drupal, joomlo, ... offer their own menus for G2 albums etc. e.g. by assembling them from theme variables. We need to offer an API for that or at least document how this can be done.
Authentication tunnelling[ ]
eads: The ability to seal off your G2 site from the public via a common authentication mechanism (like HTTP auth) but pass G2 the correct authentication information from the calling app.
valiant: Not sure if what you want is already implemented. When G2 is embedded, it is accessed through the embedding application. If you deny access to G2 in the embedding application, you can't access G2. Plus, when embedded, G2 trusts the embeddeding application. G2 doesn't do any authentication when embedded, it just accepts the activeUserId. Regarding apache / HTTP authentication: No, this isn't possible yet (forwarding the user id from apache to G2), but you can block access to G2 in the embedding application by securing the embedding application by HTTP auth.
Other stuff[ ]
valiant: What else could be ported to the G2 API side to make the life of integration authors easier?
More image block options[ ]
eads: Turn off linking in image blocks.
eads: Specifying sizes and having them autogenerated in G2. ozgreg: I have a RFE already open for this -> 1256288
Batched synchronization[ ]
valiant: Extend the initial synchronization API to do synchronization in batches of 100. If you have to synchronize a large (100k+) userbase, it might be a good idea to synchronize it in smaller batches and then refresh the webbrowser for the next batch or something like that. Since our PHP/webserver platform depends on too many external factors, we need to keep the risk for corruption as small as possible.
Group synchronization API[ ]
valiant: Extend the initial synchronization API to support group synchronization too. Extend the initial synchronization API to support group membership synchronization too.
Since group management differs between the various external applications more than basic user management, we'll have to make it general enough / add enough optional switches in the sync code etc.
Simplifying Integrations[ ]
valiant: Should the complete integrations approach be changed? How can the complexity be hidden? Or are there details that could be improved?
Variable Input / Output character encoding[ ]
valiant: Currently, we output in UTF-8 and input is expected to be UTF-8. UTF-8 support is a strict requirement for the external application. We need to introduce a variable input / output character encoding handling. At the samme time, it's quite sure that we keep the internal handling pure UTF-8.
Input should be easy, as we already run all HTTP input through GalleryUtilities.class.
Output is more difficult, since there's nothing like a output filter yet. Some data comes from the database, some is generated and some is from the templates. In the end, all output comes either from $gallery->translate (all template g->text runs through this too) or from the database. So the question is: what do we do about the db output? And of course set the HTTP header(); and the <meta html header accordingly. See: running Gallery2 (g2) in the non-UTF-8 environment
Embedding-friendly Themes[ ]
valiant: The theme documention should also address embedded themes and what to look for. E.g. css issues, relative font size, page width, no sidebars, ... Maybe tag (user contributed) themes also whether they are suited for embedded G2.
MichelleC: Bharat had a theme going for Drupal that got rid of the sidebars but the enhanced Gallery module mostly does away with the sidebars automatically so a special theme isn't needed. I much prefer that approach. Then we don't have to worry about whether a theme is suitable at least as far as the sidebars go. It needs some work, though, because sidebars still show up in site admin. Maybe some sort of global setting where "if embedded=true then all sidebars=off"?
Kiz_0987: I like MichelleC's approach and that is how the Drupal embed works -- use a normal Gallery2 theme and then add a custom css file to override the elements causing problems. This is much more maintainable than trying to derive an embed version of the Matrix theme. However, some way to add more specificity to the gallery css would be useful, to avoid issues where the embed app css affects the gallery in undesirable ways. Some G2 themes (eg matrix) are quite good, but others are not -- same goes for module css. Often the embed app will have no css specificity. I wonder if there is an automated way to do this rather than rely on the theme/module writers.
Single Website For All Integrations[ ]
dmolavi: Dariush Molavi has created EmbeddedGallery.com (right now it simply links to NukedGallery.net) to be used as a single source of Gallery embedding support. Ideally, this site would evolved into something similar to OpenSourceCMS, enabling users to view sample integrations for all the currently supported CMS/portal/blogging systems. Shameless plug: If you are a web designer and would like to design the new site, please contact Dariush Molavi via PM at NukedGallery.net for more information.
Integrations Manager[ ]
valiant: Wouldn't it be cool if there was a single G2 module or java applet with a short, intuitive step-by-step guide to integrate your G2 in another application. We'd have to introduce some standardized methods in all integrations, but it's feasible. See: G2 task: integrations manager
Integration in non-PHP applications and remote webservers[ ]
valiant: Currently, we can integrate G2 only in PHP-based applications. Once the XMLRPC module is offcially part of G2, we can expose GalleryEmbed methods to the XMLRPC interface too and enable integrations into any application and they don't even need to be on the same webserver. Session / cookie management will surely be challenging.
eads: You could also do simple non-PHP integrations using XML/OPML feeds that are retreived without remote calls (except the HTTP GET request, I suppose) to pass an album into an app like Dominey's SlideShowPro.
This would be such a great thing to do. There is NO solution on the web, with a great gallery liek back-end, and good XML export capabilties so we could use an app like slideshow pro or simpleviewer. How hard can it be to implement? The most important thing is to have a great viewing app. Gallery already does so much behind the scenes, but this lets us get that funky viewer...
Integrations with G2 as the master[ ]
valiant: We could provide a G2 module which makes integrations easier where G2 is the master in the master-slave relationship between G2 and the external application. This module would listen for GalleryEntity::save/delete events (user/group create/update/delete) and it would offer a plugin structure such that a integration writer just has to write a 1-2 file G2 module to implement a few methods: initiate the external application, create/update/delete external user.
Pbearne: This idea I would to see devopled as many sites are/start as just photo albums but the find there need some extra functions contact us form , mail members ,etc. there don't need a whole CMS and don't what to go away from the gallery themes
eads: Pbearne, you need both -- the flip side of your point is that some users (myself included, haha) want an open source digital asset management solution that integrates with this or that CMS but doesn't provide a public frontend itself and is reserved for internal use.
A different approach to embedding[ ]
MichelleC: As it is, G2 is a stand alone application that can play nice with others, but it still likes to be in control as much as possible. For my uses, I would like the ability to make G2 into a puppet with the main application pulling the strings. Other people may want G2 to have more control. To satisfy a range of needs, I propose a set of easy for the end user integration functions. These are ordered from giving G2 the most control to giving the caller the most control.
DisplayGallery() - This would drop the whole G2 into your page along the lines of http://www.plogger.org/docs/config/#integration .
DisplayFullAlbumPage(ID) - Given an album ID, this would display the whole G2 page, sidebars and all.
DisplayFullItemPage(ID) - Given an item ID, this would display the whole G2 page, sidebars and all.
GetAlbum(ID,Override) - Given an album ID, this returns just the meat of the album with no sidebars or header. The override would be a boolean to override any user permission settings so that's controlled by the calling code.
GetItem(ID,Override) - As above
GetSidebar(ID) - Given an album or item ID, this gets the sidebar that would have been displayed with it.
GetBreadCrumbs(ID) - As above
GetItemLinks(ID) - Returns an array with links to the thumb, resized, and full images. No HTML is returned. Just the URL.
GetItemInfo(ID) - Returns an array with information about the item such as whether it's an album, what sizes are available, etc.
GetNextItem(ID) - Returns the item that comes after this one in the album
GetPreviousItem(ID)
GetCustomFields(ID) - Returns an array of the custom fields for an item.
... there's many more that can go here to really dice up G2 to put it in the controlling app just how you want, but this is a start.
Setting cookies if the header has already been sent[ ]
phorum.org's embedding module has a nice idea / feature.
Problem[ ]
often, embedding means having another application outputting html at the top of G2. right now, we require that the emApp can deal with outputting only once g2 handleRequest() has been called since we need to redirect, set cookies etc.
Partial Solution[ ]
there's no simple solution for redirects (other than showing a link instead of redirecting if output has already been sent).
but for cookies, phorum.org has a nice workaround. put a <img src="main.php?g2_view=core.EmbedLogin&sessionId=..." border=0 widht=0 height=0/> at the end of the g2 output or something along these lines and the browser will then request this image url from g2 once the site is loaded and the user will get the cookie on this 2nd, invisible/transparent request. one would have to create the session in the db already before of course.