CMS Integration

would you guys mind posting the file you're using for the xaraya integration? i'm trying to get G2 integrated with mambo, and while i was able to use a script that was written for G1 (had to make a couple of modifications), it's not a complete integration, just display. i'd like to get gallery sharing user info, and i'd prefer to not haveta hack up G2 for this purpose

i'd appreciate it

User/group functions now in embed.php (cowritten by valiant and me).

1. submitted a small xaraya roles module patch. now the roles module addmember / removemember hook calls tell us what user has been added/removed from the group, before we just got the group, lol.
it's already in the current bitkeeper (cvs-like) repository of xaraya.

2. changed GalleryEmbed::addUserToGroup() to check if the user is already a member of the group before adding it. else we get multiple mappings in the maps table. I'm not yet sure if we definitely need this check, but mapping from the tree like user<->group structure of xaraya to a flat mapping is somewhat tricky.

3. Added some module variables in the xaraya gallery2 module.
// relative url from CMS root dir to G2 root dir
xarModSetVar('gallery2','g2.relativeurl','');
// absolute include path to /some/path/Gallery/
xarModSetVar('gallery2','g2.includepath','');
// if true everything is configured and ready for production
xarModSetVar('gallery2','configured',0);
I'll ask for the relative url in the xaraya gallery2 module config site and store it + the absolute include path in xaraya. This will add 1 db query for all requests (all module config vars for a specific module get loaded at once in xaraya), but there's no other solution (asking the admin to edit the file is too much and not xaraya-like).

4. I'm working on the xaraya hook functions for createUser, ...

mindless, question: when would I call GalleryEmbed::done() ?
I guess after the request was handled, right?
Or after each function of GalleryEmbed:: before giving the control back to xaraya?

mindless, thanks, that are good docs!

mindless, question:
I think we should add GalleryEmbed::updateGroup($groupname)
We can change the group name after all.

Accordingly, we should allow to change the userName too in GalleryEmbed::_setUserData(), after all you can change it in the UI too.

mindless, I'm not sure if a CMS <-> G2 user/group mapping based on the unique userName / groupName is the right approach. xaraya is surely not only CMS that allows changing the userName / groupName and G2 allows it too.
So, we're mapping on a index that can and will change.
It works, but it's not 100% reliable and the CMS has to assist to make it work by supplying the old userName for each user / group update hook call.

I'm discussing the issue with the xaraya role module author and perhaps soon with other xaraya devs.

The alternative:
A mapping based on a map table.
The map table would be part of the CMS module in G2.
table cmsMap
attribute: g_id: the id of a G2 user/group, PK
attribute: cms_id: the id of a G2 user/group

Not only the user / group create / update / delete hook calls would base on the CMS_id (instead of the userName, groupName), but the GalleryEmbed::Login and ::handleRequest methods too.
So G2 receives a CMS_ID instead of the userName. We'd have to add the CMS_ID to the GalleryUser so that this CMS_ID is cached too which helps preventing an additional database query.

Well, this is just an idea (we already had this thing before you/we decided wo map basing on the userName). I'm undicided and I'm willing to discuss this (well, I have to anyway, with the xaraya guys).

I like mapping on username because it keeps things simple.. we don't have to sync ids between dbs and we don't have to perform any extra mapping. Your changes in GalleryEmbed to allow renaming users/groups allows this method to still work.

Ok, I'm finished with the hook functions, the admin area (config/install) and the activation / initial synchronization code.
I introduced a helper/wrapper class in the gallery2 module in xaraya which eases some things, mostly the error/exception handling.

TODO:
- search integration
- get menu links from G2

Unfortunately, i had to request lots of feature in xaraya and some things are not even clear if they get implemented. So, the finished code won't work at the moment.

BUT: With the newest version of xaraya (perhaps only from bitkeeper) you can install the gallery2 module and configure it and it works. There are no constants in the code etc.
What doesn't work: Import / Export and some hooks may be erroneous, but this will only go away when the xaraya devs implement my feature requests.
Take a look at the admin page, i guess the documentation is not that bad

mindless, we should clarify which methods/functions we move from the gallery2 module in xaraya to GalleryEmbed / CMS module in g2. i.e. my parseHead function which parses the HTML head for javascript/css/title should be part of GalleryEmbed.

After my first user/group import/export implementation which is completly coded in the gallery2 module in xaraya, I have following idea:

Make this "initialUserGroupImportExport" function a part of GalleryEmbed or the CMS module in G2.
Each CMS would register it's import/export functions and then call GalleryEmbed::initialUserGroupImportExport();
Why?
Because all CMS have to to this export/import and all CMS have very much in common in this process.

example:

GalleryEmbed::initialUserGroupImportExport(array(
        'importG2Uroups' => 'someFunctionName',
        'exportCMSGroups' => ...,
        'importG2Users' =>  ...,
        'exportCMSUsers0 => ...));

And GalleryEmbed::initialUserGroupImportExport would call the registered functions accordingly with lots of common code in between.

edit: removed obsolete xaraya gallery2 module.

you're doing
list ($ret, $g2data) = GalleryEmbed::handleRequest..
right?

mindless, I could fix a dozen bugs in my xaraya gallery2 module.

But I have 1 problem though.

URLs !

All URLs that should go through the CMS are ok, I can navigate etc.

But: All direct G2 URLs are broken.

- style sheet urls:
Instead of

<style type="text/css" media="all">@import url(http://192.168.123.123/gallery2/themes/matrix/styles/theme.css);</style>
<style type="text/css" media="all">@import url(http://192.168.123.123/gallery2/layouts/matrix/layout.css.php);</style>

I get

<style type="text/css" media="all">@import url(http://gallery2/themes/matrix/styles/theme.css);</style>
<style type="text/css" media="all">@import url(http://gallery2/layouts/matrix/layout.css.php);</style>

- ShowItem / Download item URLs don't work neither.

- Slideshow URLs are broken too, with or without ShortUrls.

I tried to fix it. In GalleryUtilities::convertPathToUrl($path)
I changed $urlBase = $urlGenerator->getCurrentUrlDir(true);
to
$urlBase = $urlGenerator->getCurrentUrlDir();

But then I get

<style type="text/css" media="all">@import url(http://192.168.123.123/themes/matrix/styles/theme.css);</style>
(notice the missing gallery2/ part)

What's special with these URLs?
I guess they are all created by GalleryUtilities::convertPathToUrl($path) and some of them give a complete href as parameter.

Same setup as before:
http://192.168.123.123/xaraya-0-9-10/index.php
http://192.168.123.123/gallery2/main.php

embedUri = index.php?module=gallery2
relativeG2Path = ../gallery2/
loginRedirect = index.php?module=roles&func=register

And as I said, all other URLs are ok.

edit: removed obsolete module version attachement

Luxus, the new one? seems to be working for me. could open the zipt archive and open a file of it.

valiant, how do you configure the xaraya module? I deactivated and removed my old module, unzipped your file and activated that. I didn't see any link/option for configure, but when I visit index.php?module=gallery2 it says the module is not configured.

So I commented out the is-configured check in the module and manually set the module vars in the db.. g2.basefile needed fixing (should be filename/query param only, no path! index.php?module=gallery2) and g2.relativeurl, g2.includepath were blank so I added the values.. my G2 in xaraya comes up ok now.

Does this help you locate the problem in your install? Check your xar_module_vars table to make sure the settings are correct..

(btw, valiant.. your code needs to pass empty string to GalleryEmbed::handleRequest() when user is anonymous/guest)

I didn't want to require the username for anonymous/guest to line up between CMS and G2.. who knows, maybe some CMS don't have a "username" for this.. so the handleRequest() api specifies to pass empty string for this case.

atupid question but how i activate cms embeded in g² ?
i try to install the xaraya module and
get a error message about that

valiant, what more needs to be done for core:DownloadItem urls? I already made the changes so these go directly to G2 (do "view image" on any thumb/image to see the url).
I still don't see how to configure the module vars.. should I see "Gallery2" in the Admin/Global list, or Admin/Content? or what do I click in the Admin sidebar?

Luxus, unzip gallery2.zip in your xaraya/modules directory, then login to xaraya as an administrator and activate the module.. if you get an error, what is the error? After the module is activated you should see Gallery2 in the "Modules" list in the xaraya sidebar.

take a look at my signature, i keep an up to date version of the xaraya gallery2 module online.
fixed bug: registered the events in xarinit.php, logout works now.

online demo: http://nei.ch/test/xaraya-0-9-10/
user: admin
pass: muhmuh

G2 is in embedded only mode.

edit: corrected the url, thanks mindless.

Fixed another dozen bugs and rewrote some code in my xaraya module. Now, actually the create user, group, addmember, removemember, update user, group hooks work.
I did only test basic cases. Delete user, group, update userName, group Name, update user -> group, group -> user doesn't work ATM because of xaraya.

mindless:
1. Do you have a plan for
a) get links from G2
b) embedding configuration / embedding module in G2
c) search API (search from outside G2)

2. You can take a look at my xaraya gallery2 module (see link in signature).
Most of the code is in the xargallery2helper.php class.
Do you think it's too much code, too complicated?
Xaraya is special as i need to handle the tree/recursive structure of the user / group management, but still...
I'm not really sure if the alternative integration method where we don't synchronize users/groups but use the CMS tables would make integration easier.
We would have to write more code initially in G2, but all future integrations would have to write less code.
- no create, update, delete hook calls needed (but these should be fairly short, especially if you don't have to handle tree/recursive structures)
- initial synchronization reduces from import/export to only import user/groups (but that's not a big difference)
- less cases to test/debug

All we had to code foreach integration is:
- login / logout functions (short)
- handlerequest wrapper (short)
- [optional] search function wrapper
- [optional] language settings hooks
- But we had write some/lots of usergroupHelper classes where would have to handle the tree structure of a xaraya.

- and we would get the small performance penalty for translating all G2 db queries on the fly.

Bottom line:
I think xaraya is an exception because of the tree/recursive user/group structure. I also believe it's not too much code. But it's not as short as I hoped it would be.

note: i had the idea to move some import/export code to g2. That's not possible. As the import/export code needs to call CMS API functions again and again and we can't call CMS API functions from G2, but the other way around works.

we still could add the ext_uid attribute to the GalleryUser and synchronize with that attribute/id. it would come with zero costs as it is cached with the GalleryUser entity.

just an idea...
because it looks like i don't get my delete / update hook changes in xaraya and that would mean that i have to maintain a uid, uname, name, type table in my gallery2 module in xaraya anyway.

That sounds pretty reasonable to me. We want to synchronize with the CMS language whenever possible so we should be passing it through GalleryEmbed.

@xaraya: it looks like the discussion whether to add some update / delete hook extrainfo has come to an end and we will not get what we need.
Consequence: I need a to maintain a xaraya user id, user name, full name map.
I could create such a map in my xaraya gallery2 module.
Or we could my proposed ext_id to GalleryUser and GalleryGroup, as I've explained in previous posts.

If we have such a ext_id in the galleryUser and galleryGroup classes/db tables, we have the free choice to synchronize on a userName / groupName mapping or on the ext_id, entityId mapping.
We could update the GalleryEmbed functions to accept either userName or ext_id.

I'm for it, it's done in a few minutes, G2 doesn't need any other changes than to add ext_id attibrute to GalleryUser and GalleryGroup and we're back in business.

If we have ext_id in our GalleryUser and GalleryGroup objects, I'm for the loose coupled integration/synchronization that we do now and would say, we won't do the tight coupled on-the-fly-query translations integration.

If we add the external id to the GalleryUser class, that'll mean that we can't be embedded into two different CMSen at the same time any more. Not that this is a bad thing (I can't envision a scenario where multiple embedding isn't going to lead to weirdness or disaster).

Ernst, IIRC that Valiant considered and rejected extending GalleryUser earlier on in this thread (but maybe I'm mis-remembering)? Can one of you guys summarize the reasons why it's bad, again?

I'm torn between a) thinking that the external id has no place in the core module, and b) realizing that it's the easiest possible way to get it into the code. I guess the right thing to do is to add it in core, but be willing to refactor it into its own module if necessary.

valiant, can you explain:
1) what hooks you aren't able to get from xaraya
2) how having an ext_id <-> entityId map will solve not having those hooks

Got it, thanks.
It does sound like an id map will be helpful here. I started with the userName connection because it's easiest. Also, I do agree with changing the entire GalleryEmbed api to always work with external ids, for consistency.
But where to map it?

I thought about extending GalleryUser, and the problem with instantiating the extended class via the factory... I reached the conclusion that we probably don't want to do this, or allow any module to extend GalleryUser.. if any module extends GalleryUser (and modified the entityType of all existing users to the new type) then no other module can do the same, or it will break the first module. It seems better for other modules adding user data to maintain their own map, and not load the data along with the user entity.. then they can coexist. (Aside: maybe custom fields module should support additional user fields)

I'm tempted by the suggestion to add externalId to GalleryUser, as this keeps GalleryEmbed from having any module dependency.. but then we'd have to do the same for GalleryGroup. Another possibility is to add a single map table (entityType, externalId, galleryId) that can map both users and groups (or anything else..). This could go in an external module, but again it's nice if it's in core so GalleryEmbed has no dependency. It can just call GalleryCoreApi::loadEntityByExternalId or something..

Comments?

mindless, good points. We can't allow modules to subclass GalleryUser. Or just allow it for this special case? Bad idea.

For some external applications, the externalId may be an integer, for others a string (i.e. applications that don't have a uid integer field, but use the unique userName everywhere). And we can't just use a single map table entityId, externalId, because most applications have two sets of ids for groups and users.

Having some functions of GalleryEmbed:: depend on a embedding module isn't that bad, is it?

-> The extId fields: We could savely use a string field which would work for uid = integer and strings.
-> A seperate map table: Either have a single map table entityId, extUserId, extGroupId (like permissions table, one of those is always 0)
-> Or two mapping tables, one for users, one for groups
-> One mapping table solution for all CMS or a solution per CMS.
-> Performance! I want this externalId in the same cache object as the user entity.

baschny, if we really wanted we could add an externalApp column in the map table, to allow multiple apps to add mappings. I'd rather not offer that support by default, but the (entityType, externalId, galleryId) setup does leave the door open for someone who wants to hack together multiple-app support... ie, if someone really wants to support a single G2 embedded in multiple apps they can alter their G2 to use strings like 'xaraya-GalleryUser' or 'wordpress-GalleryUser' as the "entityType" string...

valiant, no, I guess a dependency on a module isn't that bad.. but, I haven't seen enough yet to convince me that we'll even have a CMS module in G2.. so if we put this map table in core and we don't need a cms module, great. If we decide we do need a cms module we can put the map table there.

externalId: agreed, string type
One map table: entityType+externalId = primary key
cache: good point! but you just mean you want the mapping cached, it doesn't have to literally be cached with the user data, right?

uuh, ooh, new member title

mindless, one of the xaraya devs (in contrary to 3 others, 'til now) thinks they should add the update / delete hook extrainfos we need.
If we get it, do we still do this externalId based approach?
I'm for it, because i think it's better/clearer.
I'm also not sure if userName based synchronization is really simpler.