ok, watch me flip-flop (should I run for president?)
while the above doesn't sound too complicated, it isn't trivial either.
I examined the compare-username solution a little more and determined it does not add extra overhead, so I think we should go with that.. here's why:
to do the comparison it loads the GalleryUser for the G2 active user.. this is done on every request in GalleryInitSecondPass anyway.. so, a bit earlier we'll load the user (usually from disk cache) and then later GalleryInitSecondPass will get it from memory cache. Only when it is determined the active user has changed to a new non-guest user does it do an extra db operation (fetchUserByUserName).
I'll still do item 3 above, so we reset any existing g2 sessions on cms logout.
bd_csmc
Joined: 2004-10-01
Posts: 1
Posted: Fri, 2004-10-01 18:56
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
mindless
Joined: 2004-01-04
Posts: 8601
Posted: Fri, 2004-10-01 21:12
Here's the code I'm working with.. valiant's may be more up to date.
We only ensure login/logout match between CMS and G2 sessions so far.. we're getting close on syncing user create/update/delete, group create/delete/membership changes, but aren't there yet.
mindless
Joined: 2004-01-04
Posts: 8601
Posted: Sat, 2004-10-02 00:45
User/group functions now in embed.php (cowritten by valiant and me).
Luxus
Joined: 2004-07-07
Posts: 30
Posted: Wed, 2004-10-06 02:50
you guys are great... i will wait for g²beta but then i will play arround with it :D
valiant
Joined: 2003-01-04
Posts: 32509
Posted: Tue, 2004-10-12 20:43
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
Joined: 2004-01-04
Posts: 8601
Posted: Tue, 2004-10-12 21:04
Quote:
question: when would I call GalleryEmbed::done() ?
Only call this once, after all G2 processing is done for this request.
(I added some info on this near the top of embed.php)
valiant
Joined: 2003-01-04
Posts: 32509
Posted: Wed, 2004-10-13 00:29
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.
valiant
Joined: 2003-01-04
Posts: 32509
Posted: Wed, 2004-10-13 01:43
requested 2,3 other xaraya roles module patches, hope to get them included.
(update hook details, ...)
mindless, changed embed.php updateUser and added updateGroup to make userName / groupName changes possible.
If you don't agree/change it back, please tell me why
edit: removed obsolete module version attachement
valiant
Joined: 2003-01-04
Posts: 32509
Posted: Wed, 2004-10-13 16:36
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).
valiant
Joined: 2003-01-04
Posts: 32509
Posted: Wed, 2004-10-13 16:50
I'm writing more and more stuff for the xaraya gallery2 module. Now I know what is part of the xaraya gallery2 module and what is part of the G2 CMS module.
G2 CMS module:
Module Plugin parameter:
- Show Login link (redirecting to CMS login page)
- Show Your Account link
- Show Memberlist link
- Show search link/box (assuming we will integrate G2 search in CMS)
- Allow browsing directly to G2 (without the CMS layout around it)
(setting this to false would mean to reject all G2 requests but the DownloadItem request). (or leave this config var in config.php)
- plus the 'G2Embedded' = 1 | 0, parameter. This just indicates that the CMS module is active, we could alternatively just check if the module is active.
This module should also disable the registration capabilities (on API level).
xaraya gallery2 module:
I'm nearly finished with the code, or I think so. I've added some good docs in the admin view of the gallery2 module that explains how it works, what to do in what order.
It works like this:
1. install xaraya
2. install G2
3. install CMS module in G2, activate it
4. install gallery2 module in xaraya -> not configured, not working
5. configure gallery2 module in xaraya: set relative path to G2 installation.
if path is correct, i require the embed.php, then check if G2 is in embedded mode.
Then comes the user/group import/export basing on the userNames:
// 1. import G2 groups to xaraya (if already exists, skip)
// 2. export xaraya roles of type 1 = groups to G2
// 3. delete G2 pending users
// 4. import G2 users to xaraya (if already exists, skip)
// 5. export xaraya roles of type 0 = users to G2, update if already exists
set configured = true and we are done.
The whole user import/export process is initiated by the CMS and part of the CMS and I think this is the best solution.
We can code a single G2 CMS module for all CMS/forums, no CMS specific code is part of this module.
mindless
Joined: 2004-01-04
Posts: 8601
Posted: Wed, 2004-10-13 16:50
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.
valiant
Joined: 2003-01-04
Posts: 32509
Posted: Wed, 2004-10-13 17:01
mindless, please take a look at my last post, we posted nearly simultaneously, perhaps you didn't see it.
I like the mapping based on userNames too, because it's simple. That's the main argument I instanced (hope this englesa).
BUT: There are some special groups (admins, allusers, everybody) and the anonymous user. Most CMS share this principle of special users, i.e. xaraya has exactly the same special groups/user. At least on the inital export/import I need to map these groups/user on their special IDs (pluginparameter).
And on all create / update / delete hook calls I need to be aware of these special groups/user too.
At least we don't need to translate the userName for each request, we just have to make sure that the AnonymousUser has the same name in G2 and in the CMS, i.e. we would have to update the userName of "Guest" to "anonymous" on module installation time.
All I say: It works with userName maps, but it's perhaps not the best solution. The special groups/user show that the userName mapping is not as simple as it might look like, but still, it's simpler (and a little bit less reliable) than a mapping basing on IDs.
valiant
Joined: 2003-01-04
Posts: 32509
Posted: Fri, 2004-10-15 00:54
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.
And GalleryEmbed::initialUserGroupImportExport would call the registered functions accordingly with lots of common code in between.
edit: removed obsolete xaraya gallery2 module.
valiant
Joined: 2003-01-04
Posts: 32509
Posted: Fri, 2004-10-15 03:45
mindless, the current version of my xaraya module seems to work.
But the returned array of GalleryEmbed::handleRequest($username);
doesn't have "isDone" as an index!
- 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();
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.
Luxus, the new one? seems to be working for me. could open the zipt archive and open a file of it.
Luxus
Joined: 2004-07-07
Posts: 30
Posted: Fri, 2004-10-15 16:17
strange ... just some seconds ago i got a message about that the attachment not exist...
mindless
Joined: 2004-01-04
Posts: 8601
Posted: Fri, 2004-10-15 16:35
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)
valiant
Joined: 2003-01-04
Posts: 32509
Posted: Fri, 2004-10-15 17:21
mindless, thanks! That was yet another bug. I used $_SERVER['SCRIPT_NAME'] instead of $scriptName = preg_replace('|/([^/]+/)*|', '', $_SERVER['SCRIPT_NAME']);
Now it works. All URLs are correct !!
I fixed the anonymous user thing. But why should i not pass the anonymous user?
the xaraya module configuration is done it the Admin panel.
In a vanilla xaraya, you have the user menu at the left side on top and the admin menu on the bottom, if you're logged in as admin.
Here's the fixed version of the xaraya gallery2 module.
mindless, I'm also using the latest xaraya version from the dev repository through bitkeeper. If you want, I could post a url to the latest version i downloaded.
1, 2 things in the roles module are already implemented/fixed since the 0.9.10 version.
edit: removed an obsolete xaraya gallery2 module version attachement.
mindless
Joined: 2004-01-04
Posts: 8601
Posted: Fri, 2004-10-15 17:32
Quote:
I fixed the anonymous user thing. But why should i not pass the anonymous user?
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.
valiant
Joined: 2003-01-04
Posts: 32509
Posted: Fri, 2004-10-15 17:47
Ok, agreed.
Noticed that the upload applet doesn't work in embedded mode.
It loads the applet, but the upload applet doesn't find a Gallery protocol implementation at the target url.
And the cancel button of the applet doesn't work and it shows "uploading m of n", whereas m and n are not replaced with numbers.
mindless, could you change what is needed to create direct G2 DownloadItem urls? They should go directly to G2, not via the CMS baseUrl etc.
Luxus
Joined: 2004-07-07
Posts: 30
Posted: Fri, 2004-10-15 18:03
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
Joined: 2003-01-04
Posts: 32509
Posted: Fri, 2004-10-15 18:14
I guess you refer to "mode.embed.only".
As we don't have a CMS module in G2, not yet, I use the
$gallery->setConfig('mode.embed.only', true);
in the config.php of G2, set it to true during the xaraya admin gallery2 module config process.
mindless
Joined: 2004-01-04
Posts: 8601
Posted: Fri, 2004-10-15 18:24
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.
valiant
Joined: 2003-01-04
Posts: 32509
Posted: Fri, 2004-10-15 18:42
mindless, my bad. The DownloadItem urls are ok, sorry.
@configuration:
After you have installed the Gallery2 module, you see a "Gallery2" menu item in the user menu and a "Gallery2" menu item in the Admin->Content part of the menu.
Then click on "Gallery2"->Modify Config.
And I said, you need to set
$gallery->setConfig('mode.embed.only', true); during modify config time, it's a dirty fix until we have a G2 CMS module.
valiant
Joined: 2003-01-04
Posts: 32509
Posted: Fri, 2004-10-15 21:04
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.
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.
valiant
Joined: 2003-01-04
Posts: 32509
Posted: Sun, 2004-10-17 15:03
@language code:
I can hand over the current language code from xaraya to G2 on each request at nearly no cost.
I will set the G2 user language code whenever it's updated in xaraya, but for anonymous users and generally for session var updates I cannot submit the change to G2, but as I said, handing over the language/locale to G2 in GalleryEmbed::handlerequest would be perfect, IMO.
The format is "en_US.utf-8", it's like the lang code of G2, but there are .utf-8, ... extensions.
My questions:
a) locale format: will G2 ever have extensions like .utf-8 or will the language codes always be lang_COUNTRY ?
If so, I just hand over the G2 format and in GalleryEmbed we should set the lang code with fallback = true
b) Do you think it's a good idea to hand over the language code on each request (at no cost)?
update: i hand over the lang code as lang_COUNTRY to handleRequest and in GalleryEmbed::handleRequest($userName=null, $langCode=null) i set the session language after running the langCode through GalleryTranslater::getSupportedLanguageCode($languageCode, $fallback=true) and it works.
Let me know if you don't agree with this (perhaps slow?) approach.
valiant
Joined: 2003-01-04
Posts: 32509
Posted: Sun, 2004-10-17 22:11
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.
i hand over the lang code as lang_COUNTRY to handleRequest and in GalleryEmbed::handleRequest($userName=null, $langCode=null) i set the session language after running the langCode through GalleryTranslater::getSupportedLanguageCode($languageCode, $fallback=true) and it works.
Let me know if you don't agree with this (perhaps slow?) approach.
That sounds pretty reasonable to me. We want to synchronize with the CMS language whenever possible so we should be passing it through GalleryEmbed.
valiant
Joined: 2003-01-04
Posts: 32509
Posted: Mon, 2004-10-18 00:34
update:
added short url and short url synchronization support.
as usual, remove/reinstall the gallery2 module.
valiant
Joined: 2003-01-04
Posts: 32509
Posted: Mon, 2004-10-18 11:31
@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.
baschny
Joined: 2003-01-04
Posts: 328
Posted: Mon, 2004-10-18 11:40
valiant, instead of adding that info into GalleryUser, why not extend GalleryUser in the xaraya-module to be created? Something like
class XarayaUser extends GalleryUser {
var $_xarayaId;
...
}
This would create a new G2-table for XarayaUsers.
This way the same G2 install could be integrated in more than one CMS at the same time, just have multiple classes extending GalleryUser. Maybe sometime later another CMS needs to add more info to the GalleryUser, etc.
bharat
Joined: 2002-05-21
Posts: 7994
Posted: Mon, 2004-10-18 17:25
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
Joined: 2003-01-04
Posts: 32509
Posted: Mon, 2004-10-18 18:08
bharat, Ernst: There are two processes involved.
1. create, update, delete User/Group entities.
2. handle request
For 2. we don't really need the ext_id, because userNames are unique and work perfectly in GalleryEmbed::handlerequest().
For 1. update and delete operations, I need the ext_id <-> entityId mapping. It doesn't matter if this information is not cached, because it's only used very rarely.
It also makes more sense to map a gallery user to a CMS user on the id, because the id is the only that doesn't change.
Now that we know that we need the ext_id <-> entityId mapping, we should ask us, if we don't want to handle everything (also 2.) with this map, just because it would be more unified.
And if we want to handle all requests with the ext_id, we need this ext_id<->entityId map cached.
If I create a XarayaGalleryUser extends GalleryUser class, where should I do this? In the xaraya gallery2 module? In a embedding module in G2? And how would I register my factoryimplementation to make sure Gallery uses this class for all GalleryUser factory requests?
A few months ago I spoke to bharat, because the factory thing doesn't work like it should (exactly this case was not possible, you couldn't register a XarayaGalleryUser as an implementation for a GalleryEntity with the goal that all GalleryUser factory requests would return a XarayaGalleryUser.
However, we need this ext_id <-> entityId map, where should it go?
Thanks
mindless
Joined: 2004-01-04
Posts: 8601
Posted: Mon, 2004-10-18 18:21
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
valiant
Joined: 2003-01-04
Posts: 32509
Posted: Mon, 2004-10-18 18:34
mindless, sure, sorry, didn't explain that.
I have all hooks I need in xaraya. But the philosophy behind the hook calls is that they only inform you who called the hooks (which module) and which objects are involved. i.e. the roles (user, group management) calls the item update hook for role with itemid 15 and of itemtype 0.
Now all hooked modules know that the user with the uid 15 has been updated. If they want to know more, they should use the API to get that info.
In case of update user / group hooks, we get the uid and itemtype. With the uid I can the updated data from the API. But I don't know the state before the update.
That is a problem if the userName was changed. I only have the new userName, how should I know which G2 user maps to this xaraya user from changed userName?
Other case: in xaraya, a role is either a user or a group. You can update a empty group to become a user, or a user can be made a group by a click. How should my update function know that the in the old state, the user was a group?
Other case: delete user / group hook calls. I only get the uid, no userName. I can't delete a G2 user that I don't know.
The userName based synchronization is a map on a changing index, which is...bad.
How would the ext_id <-> entityId map fix the problem?
If i get a delete hook call, I can just ask G2 (the map) who uid x is or for update hook calls, I can check the old dataset for uid in G2 and update the diff in G2.
mindless
Joined: 2004-01-04
Posts: 8601
Posted: Tue, 2004-10-19 17:36
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?
baschny
Joined: 2003-01-04
Posts: 328
Posted: Tue, 2004-10-19 17:59
mindless, I like your suggestions, keeping the map "G2-id vs External-id" in the Core, but separated from GalleryUser. The only problem with that is that G2 can only be integrated in one CMS per G2-installation, but I think this is not a big problem.
valiant
Joined: 2003-01-04
Posts: 32509
Posted: Tue, 2004-10-19 18:03
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
Joined: 2003-01-04
Posts: 328
Posted: Tue, 2004-10-19 18:08
valiant, instead of having CMS-dependant info in GalleryEmbed, I would rather make a separate CMS-module in Gallery. G2-core could provide an interface to this user/group/internal/external "mapping" functionality that GalleryEmbed can use and which each CMS-module could implement (as a map or however).
mindless
Joined: 2004-01-04
Posts: 8601
Posted: Tue, 2004-10-19 18:16
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?
valiant
Joined: 2003-01-04
Posts: 32509
Posted: Tue, 2004-10-19 21:58
mindless wrote:
One map table: entityType+externalId = primary key
perhaps my logic module is already shut down due to alcohol abuse, but i disagree. the external app gives us the externalId and we should find the entityId that matches this externalId, right? As I said, the external application most probably has two different tables for users and groups and most probably has two sets of ids, one set for users, one for groups.
there may be an entry in the user table of the external application with userId = 1, userName = john, at the same time there's the groupId = 1, groupName=idiots.
Now, G2 receives a synchronization / handlerequest call.
You see, a "loadEntitiesByExtId($extId) doesn't work because there are two entries in your single map table that match externalId = "1".
Wait, it works, you must have thought of this
Just join the map table on the entities table and specify whether you want a user or a group.
loadEntitiesByExtIds() should have a secoond parameter, a hint "GalleryUser" or "GalleryGroup" for each id we request.
But: Here comes xaraya which can transform a groups into a users and users into groups just by clicking on a button in the admin panel.
If xaraya had different sets of ids for users and groups, we would have a serious problem, because on a update hook call we wouldn't know whether the object previously was a user or a group and thus couldn't tell G2 what we want (there could be two entries in the map table matching our extId, but we can't specify which one we want).
However, xaraya has only 1 set of ids for users and groups and that's why we always would know what to return for a specific externalId.
So, the second optional parameter, the hint, should be optional. loadEntitiesByExtIds($extIds, $hint=null)
if loadEntitiesByExtIds finds more than count($extIds) results, raise an exception.
I agree, we only need one map table: entityId, externalId, galleryId (for baschny's mutli gallery install proposal?).
But how do we get this entityId <-> extId map into the GalleryUser entity filesystem cached objects or into the session cache?
mindless: why a cms module? just for the configs. i think this config flags would be very cool and putting them into the core, dunno...
valiant
Joined: 2003-01-04
Posts: 32509
Posted: Tue, 2004-10-19 22:35
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.
Posts: 8601
ok, watch me flip-flop (should I run for president?)
while the above doesn't sound too complicated, it isn't trivial either.
I examined the compare-username solution a little more and determined it does not add extra overhead, so I think we should go with that.. here's why:
to do the comparison it loads the GalleryUser for the G2 active user.. this is done on every request in GalleryInitSecondPass anyway.. so, a bit earlier we'll load the user (usually from disk cache) and then later GalleryInitSecondPass will get it from memory cache. Only when it is determined the active user has changed to a new non-guest user does it do an extra db operation (fetchUserByUserName).
I'll still do item 3 above, so we reset any existing g2 sessions on cms logout.
Posts: 1
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
Posts: 8601
Here's the code I'm working with.. valiant's may be more up to date.
We only ensure login/logout match between CMS and G2 sessions so far.. we're getting close on syncing user create/update/delete, group create/delete/membership changes, but aren't there yet.
Posts: 8601
User/group functions now in embed.php (cowritten by valiant and me).
Posts: 30
you guys are great... i will wait for g²beta but then i will play arround with it :D
Posts: 32509
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?
Posts: 8601
Only call this once, after all G2 processing is done for this request.
(I added some info on this near the top of embed.php)
Posts: 32509
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.
Posts: 32509
requested 2,3 other xaraya roles module patches, hope to get them included.
(update hook details, ...)
I've completed:
xaraya/modules/gallery2/xaradminapi/ hook functions:
create.php -> createUser, createGroup, addmember
update.php -> updateUser, updateGroup
delete.php -> deleteUser, deleteGroup, removemember
Next:
- Create admin view: modify_config.php
- search hook
mindless, changed embed.php updateUser and added updateGroup to make userName / groupName changes possible.
If you don't agree/change it back, please tell me why
edit: removed obsolete module version attachement
Posts: 32509
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).
Posts: 32509
I'm writing more and more stuff for the xaraya gallery2 module. Now I know what is part of the xaraya gallery2 module and what is part of the G2 CMS module.
G2 CMS module:
Module Plugin parameter:
- Show Login link (redirecting to CMS login page)
- Show Your Account link
- Show Memberlist link
- Show search link/box (assuming we will integrate G2 search in CMS)
- Allow browsing directly to G2 (without the CMS layout around it)
(setting this to false would mean to reject all G2 requests but the DownloadItem request). (or leave this config var in config.php)
- plus the 'G2Embedded' = 1 | 0, parameter. This just indicates that the CMS module is active, we could alternatively just check if the module is active.
This module should also disable the registration capabilities (on API level).
xaraya gallery2 module:
I'm nearly finished with the code, or I think so. I've added some good docs in the admin view of the gallery2 module that explains how it works, what to do in what order.
It works like this:
1. install xaraya
2. install G2
3. install CMS module in G2, activate it
4. install gallery2 module in xaraya -> not configured, not working
5. configure gallery2 module in xaraya: set relative path to G2 installation.
if path is correct, i require the embed.php, then check if G2 is in embedded mode.
Then comes the user/group import/export basing on the userNames:
// 1. import G2 groups to xaraya (if already exists, skip)
// 2. export xaraya roles of type 1 = groups to G2
// 3. delete G2 pending users
// 4. import G2 users to xaraya (if already exists, skip)
// 5. export xaraya roles of type 0 = users to G2, update if already exists
set configured = true and we are done.
The whole user import/export process is initiated by the CMS and part of the CMS and I think this is the best solution.
We can code a single G2 CMS module for all CMS/forums, no CMS specific code is part of this module.
Posts: 8601
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.
Posts: 32509
mindless, please take a look at my last post, we posted nearly simultaneously, perhaps you didn't see it.
I like the mapping based on userNames too, because it's simple. That's the main argument I instanced (hope this englesa).
BUT: There are some special groups (admins, allusers, everybody) and the anonymous user. Most CMS share this principle of special users, i.e. xaraya has exactly the same special groups/user. At least on the inital export/import I need to map these groups/user on their special IDs (pluginparameter).
And on all create / update / delete hook calls I need to be aware of these special groups/user too.
At least we don't need to translate the userName for each request, we just have to make sure that the AnonymousUser has the same name in G2 and in the CMS, i.e. we would have to update the userName of "Guest" to "anonymous" on module installation time.
All I say: It works with userName maps, but it's perhaps not the best solution. The special groups/user show that the userName mapping is not as simple as it might look like, but still, it's simpler (and a little bit less reliable) than a mapping basing on IDs.
Posts: 32509
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.
Posts: 32509
mindless, the current version of my xaraya module seems to work.
But the returned array of GalleryEmbed::handleRequest($username);
doesn't have "isDone" as an index!
What's wrong?
My setup:
/xaraya-0-9-10/index.php
/gallery2/main.php
embedUri = index.php?module=gallery2
relativeG2Path = ../gallery2/
loginRedirect = index.php?module=roles&func=register
Posts: 8601
you're doing
list ($ret, $g2data) = GalleryEmbed::handleRequest..
right?
Posts: 32509
mindless, thanks. It was very very late, that was exactly my error.
Posts: 32509
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
Posts: 30
the attachment is broken..
Posts: 32509
Luxus, the new one? seems to be working for me. could open the zipt archive and open a file of it.
Posts: 30
strange ... just some seconds ago i got a message about that the attachment not exist...
Posts: 8601
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)
Posts: 32509
mindless, thanks! That was yet another bug. I used $_SERVER['SCRIPT_NAME'] instead of $scriptName = preg_replace('|/([^/]+/)*|', '', $_SERVER['SCRIPT_NAME']);
Now it works. All URLs are correct !!
I fixed the anonymous user thing. But why should i not pass the anonymous user?
the xaraya module configuration is done it the Admin panel.
In a vanilla xaraya, you have the user menu at the left side on top and the admin menu on the bottom, if you're logged in as admin.
Here's the fixed version of the xaraya gallery2 module.
mindless, I'm also using the latest xaraya version from the dev repository through bitkeeper. If you want, I could post a url to the latest version i downloaded.
1, 2 things in the roles module are already implemented/fixed since the 0.9.10 version.
edit: removed an obsolete xaraya gallery2 module version attachement.
Posts: 8601
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.
Posts: 32509
Ok, agreed.
Noticed that the upload applet doesn't work in embedded mode.
It loads the applet, but the upload applet doesn't find a Gallery protocol implementation at the target url.
And the cancel button of the applet doesn't work and it shows "uploading m of n", whereas m and n are not replaced with numbers.
mindless, could you change what is needed to create direct G2 DownloadItem urls? They should go directly to G2, not via the CMS baseUrl etc.
Posts: 30
atupid question but how i activate cms embeded in g² ?
i try to install the xaraya module and
get a error message about that
Posts: 32509
I guess you refer to "mode.embed.only".
As we don't have a CMS module in G2, not yet, I use the
$gallery->setConfig('mode.embed.only', true);
in the config.php of G2, set it to true during the xaraya admin gallery2 module config process.
Posts: 8601
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.
Posts: 32509
mindless, my bad. The DownloadItem urls are ok, sorry.
@configuration:
After you have installed the Gallery2 module, you see a "Gallery2" menu item in the user menu and a "Gallery2" menu item in the Admin->Content part of the menu.
Then click on "Gallery2"->Modify Config.
Or if you really can't see this menu item ?!?! browse to
http://192.168.123.123/xaraya-0-9-10/index.php?module=gallery2&type=admin (replace some url parts for your installation)
or directly to
http://192.168.123.123/xaraya-0-9-10/index.php?module=gallery2&type=admin&func=modifyconfig
And I said, you need to set
$gallery->setConfig('mode.embed.only', true); during modify config time, it's a dirty fix until we have a G2 CMS module.
Posts: 32509
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.
Posts: 8601
demo url is missing "test/" in the path...
Posts: 32509
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.
Posts: 32509
@language code:
I can hand over the current language code from xaraya to G2 on each request at nearly no cost.
I will set the G2 user language code whenever it's updated in xaraya, but for anonymous users and generally for session var updates I cannot submit the change to G2, but as I said, handing over the language/locale to G2 in GalleryEmbed::handlerequest would be perfect, IMO.
The format is "en_US.utf-8", it's like the lang code of G2, but there are .utf-8, ... extensions.
My questions:
a) locale format: will G2 ever have extensions like .utf-8 or will the language codes always be lang_COUNTRY ?
If so, I just hand over the G2 format and in GalleryEmbed we should set the lang code with fallback = true
b) Do you think it's a good idea to hand over the language code on each request (at no cost)?
update: i hand over the lang code as lang_COUNTRY to handleRequest and in GalleryEmbed::handleRequest($userName=null, $langCode=null) i set the session language after running the langCode through GalleryTranslater::getSupportedLanguageCode($languageCode, $fallback=true) and it works.
Let me know if you don't agree with this (perhaps slow?) approach.
Posts: 32509
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.
Posts: 32509
updated the task on sf.net:
http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=103297&group_id=7130&group_project_id=14056
Posts: 7994
That sounds pretty reasonable to me. We want to synchronize with the CMS language whenever possible so we should be passing it through GalleryEmbed.
Posts: 32509
update:
added short url and short url synchronization support.
as usual, remove/reinstall the gallery2 module.
Posts: 32509
@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.
Posts: 328
valiant, instead of adding that info into GalleryUser, why not extend GalleryUser in the xaraya-module to be created? Something like
class XarayaUser extends GalleryUser { var $_xarayaId; ... }This would create a new G2-table for XarayaUsers.
This way the same G2 install could be integrated in more than one CMS at the same time, just have multiple classes extending GalleryUser. Maybe sometime later another CMS needs to add more info to the GalleryUser, etc.
Posts: 7994
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.
Posts: 32509
bharat, Ernst: There are two processes involved.
1. create, update, delete User/Group entities.
2. handle request
For 2. we don't really need the ext_id, because userNames are unique and work perfectly in GalleryEmbed::handlerequest().
For 1. update and delete operations, I need the ext_id <-> entityId mapping. It doesn't matter if this information is not cached, because it's only used very rarely.
It also makes more sense to map a gallery user to a CMS user on the id, because the id is the only that doesn't change.
Now that we know that we need the ext_id <-> entityId mapping, we should ask us, if we don't want to handle everything (also 2.) with this map, just because it would be more unified.
And if we want to handle all requests with the ext_id, we need this ext_id<->entityId map cached.
If I create a XarayaGalleryUser extends GalleryUser class, where should I do this? In the xaraya gallery2 module? In a embedding module in G2? And how would I register my factoryimplementation to make sure Gallery uses this class for all GalleryUser factory requests?
A few months ago I spoke to bharat, because the factory thing doesn't work like it should (exactly this case was not possible, you couldn't register a XarayaGalleryUser as an implementation for a GalleryEntity with the goal that all GalleryUser factory requests would return a XarayaGalleryUser.
However, we need this ext_id <-> entityId map, where should it go?
Thanks
Posts: 8601
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
Posts: 32509
mindless, sure, sorry, didn't explain that.
I have all hooks I need in xaraya. But the philosophy behind the hook calls is that they only inform you who called the hooks (which module) and which objects are involved. i.e. the roles (user, group management) calls the item update hook for role with itemid 15 and of itemtype 0.
Now all hooked modules know that the user with the uid 15 has been updated. If they want to know more, they should use the API to get that info.
In case of update user / group hooks, we get the uid and itemtype. With the uid I can the updated data from the API. But I don't know the state before the update.
That is a problem if the userName was changed. I only have the new userName, how should I know which G2 user maps to this xaraya user from changed userName?
Other case: in xaraya, a role is either a user or a group. You can update a empty group to become a user, or a user can be made a group by a click. How should my update function know that the in the old state, the user was a group?
Other case: delete user / group hook calls. I only get the uid, no userName. I can't delete a G2 user that I don't know.
The userName based synchronization is a map on a changing index, which is...bad.
How would the ext_id <-> entityId map fix the problem?
If i get a delete hook call, I can just ask G2 (the map) who uid x is or for update hook calls, I can check the old dataset for uid in G2 and update the diff in G2.
Posts: 8601
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?
Posts: 328
mindless, I like your suggestions, keeping the map "G2-id vs External-id" in the Core, but separated from GalleryUser. The only problem with that is that G2 can only be integrated in one CMS per G2-installation, but I think this is not a big problem.
Posts: 32509
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.
Posts: 328
valiant, instead of having CMS-dependant info in GalleryEmbed, I would rather make a separate CMS-module in Gallery. G2-core could provide an interface to this user/group/internal/external "mapping" functionality that GalleryEmbed can use and which each CMS-module could implement (as a map or however).
Posts: 8601
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?
Posts: 32509
perhaps my logic module is already shut down due to alcohol abuse, but i disagree. the external app gives us the externalId and we should find the entityId that matches this externalId, right? As I said, the external application most probably has two different tables for users and groups and most probably has two sets of ids, one set for users, one for groups.
there may be an entry in the user table of the external application with userId = 1, userName = john, at the same time there's the groupId = 1, groupName=idiots.
Now, G2 receives a synchronization / handlerequest call.
You see, a "loadEntitiesByExtId($extId) doesn't work because there are two entries in your single map table that match externalId = "1".
Wait, it works, you must have thought of this
Just join the map table on the entities table and specify whether you want a user or a group.
loadEntitiesByExtIds() should have a secoond parameter, a hint "GalleryUser" or "GalleryGroup" for each id we request.
But: Here comes xaraya which can transform a groups into a users and users into groups just by clicking on a button in the admin panel.
If xaraya had different sets of ids for users and groups, we would have a serious problem, because on a update hook call we wouldn't know whether the object previously was a user or a group and thus couldn't tell G2 what we want (there could be two entries in the map table matching our extId, but we can't specify which one we want).
However, xaraya has only 1 set of ids for users and groups and that's why we always would know what to return for a specific externalId.
So, the second optional parameter, the hint, should be optional. loadEntitiesByExtIds($extIds, $hint=null)
if loadEntitiesByExtIds finds more than count($extIds) results, raise an exception.
I agree, we only need one map table: entityId, externalId, galleryId (for baschny's mutli gallery install proposal?).
But how do we get this entityId <-> extId map into the GalleryUser entity filesystem cached objects or into the session cache?
mindless: why a cms module? just for the configs. i think this config flags would be very cool and putting them into the core, dunno...
Posts: 32509
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.