mindless: i'd like to work on G2/xaraya on the weekend, but first, i need to know how we do this entityId<->externalId map :/ . already know where to put it (condition: fast access / translation from extId to entityId / userName)? that's a problem. we can't build a filesystem cache of this map that scales good. if we can add this externalId to the session data, we only need to query the map when a non anonymous user creates a new session and that's a good thing IMO.
if we want to filesystem cache this map, we should only map the last x and y most requested mappings if the total number of mappings exceeds a certain number, or is this too complicated for such a thing?
mindless
Joined: 2004-01-04
Posts: 8601
Posted: Fri, 2004-10-22 17:18
valiant, I am setting up the api so that we could support hint=null if we want.. however, how will that api allow you to process xaraya's user<->group changes? I think we should just not support that, or else xaraya's gallery2 module needs to handle it.. I don't want to add user<->group morphing in GalleryEmbed... what does it even mean to take a group of ten users and convert that group into a user? combine all permissions of those ten users and assign them to this new user??
mindless
Joined: 2004-01-04
Posts: 8601
Posted: Fri, 2004-10-22 19:40
Ok, added the map, core api, and updated GalleryEmbed to work with external ids instead of username/groupname. valiant, I used your suggestion to put external user id in the G2 session, to make for an easier _checkActiveUser routine.. good idea! With that in place I didn't do any caching (yet) for the ExternalIdMap.. we can decide later if caching is needed.
mindless
Joined: 2004-01-04
Posts: 8601
Posted: Fri, 2004-10-22 21:07
on irc valiant made the good point that we could join to the Entity table to find entityType rather than store it in the map table.. after some discussion we decided to leave it in the map table. Three reasons:
1) embed code will still work even if some module changes the entity type for a user or group (even though from discussion above we don't think they should)
2) leaves open the hack possibility I mentioned above for supporting entityType string like 'xaraya-GalleryUser'
3) map query will be very fast (querying on primary key).. join would join primary key of 2 tables, so it probably wouldn't be too much slower though
valiant
Joined: 2003-01-04
Posts: 32509
Posted: Sun, 2004-10-24 22:22
I changed the gallery2 module to synchronize users and groups based on the new mapping rather than the former userName/groupName approach.
I still have to fix 1,2 bugs and wait for xaraya devs to agree on some minor roles module changes before I upload the new version of the xaraya gallery2 module.
The initial user/group import/export is still based on userNames/groupNames as there's no uid<->entityId at the time of this initial synchronization. This makes the import/export code rather bloated, but the rest, the create, update, delete hooks are quite short in code.
I think it's a good idea to check on $gallery->setConfig('mode.embed.only', true); during xaraya gallery2 module configuration/import/export time. It's like the G2 maintenance mode i proposed, it ensures that all G2 interactions run through the CMS and the CMS blocks all G2 requests until the gallery2 module has been configured. Having no changes in G2 during the user import/export is a very good thing
valiant
Joined: 2003-01-04
Posts: 32509
Posted: Tue, 2004-10-26 21:31
mindless, it would be great if you could up with one of your ingenious over night ideas/implementations for the menu links ;)
We need also a template without menu/search block/imageblock.
(The whole left column).
Today, I filed another 2 xaraya bugs. One in the event system and yet another roles module bug. This really sucks.
darkice
Joined: 2004-10-26
Posts: 2
Posted: Tue, 2004-10-26 23:48
Hy EveryBody..
I've installed Gallery2 via CVS and works perfectly; after i've installed Xaraya
and i've downloaded the g2 module and installed it in xaraya.
When i go to set the relative path to my gallery2 path, i find this error:
How recently did you run the G2 installer? Make sure you have a g2_ExternalIdMap table in your G2 db.. if not, reinstall G2 with latest cvs.
valiant
Joined: 2003-01-04
Posts: 32509
Posted: Wed, 2004-10-27 06:04
darkice,
the current xaraya gallery2 module in my signature is obsolete, it still synchronizes based on usernames.
a new xaraya gallery2 module compatible with the current G2 release is actually ready, but there are still issues with xaraya. and i haven't tested it thouroughly.
give me another 2-3 days for a more bug free module.
darkice
Joined: 2004-10-26
Posts: 2
Posted: Wed, 2004-10-27 13:16
mindless wrote:
How recently did you run the G2 installer? Make sure you have a g2_ExternalIdMap table in your G2 db.. if not, reinstall G2 with latest cvs.
I've reinstalled G2 with latest cvs and now i can see the table g2_ExternalIdMap.
Unfortunately i've found the some problem (the list of errors).
So i'm waiting for the new module release..
Regards.
valiant
Joined: 2003-01-04
Posts: 32509
Posted: Sat, 2004-10-30 18:40
mindless, the imageblock module generates a sample url <?php @readfile('http://192.168.123.123/xaraya-0-9-10/index.php?module=gallery2?g2_view=imageblock:External&g2_blocks=randomImage&g2_show=title'); ?>which is slightly wrong. after embedURI it should start with & in this case. Do you use the GalleryUrlGenerator for this?
However, I'd like to include some blocks in xaraya. Should I use it like
$data['imageblock'] = @readfile(xarModGetVar('gallery2','g2.basefile') . '&g2_view=imageblock:External&g2_blocks=randomImage&g2_show=title');
?
I think it would be better to call init the G2 API and then access the imageblock API, right?
Get menu links still has the top priority though...
baschny
Joined: 2003-01-04
Posts: 328
Posted: Sat, 2004-10-30 21:40
valiant wrote:
Get menu links still has the top priority though...
If you are talking about the "navigation" links on the sidebar (called SystemLinks), be aware that after my navigation patch (to be released soon), most (all) of them will be gone:
- Site Admin, Login, Your Account, Logout will be moved to the header line
- "View Cart" and "Members list" will be placed on its own SystemContent Blocks in the sidebar, together with more module information (e.g. items in cart and total number of members)
The sidebar on the left will be left just with a bunch of SystemContent's. We will make very sparingly use of SystemLinks, as they will be placed in a new horizontal menu on the top bar (to the right of the breadcrumb). The only left "links" in the sidebar are the "current items's action", which is generated by our matrix layout.
So now the question is: What SystemContent's do we need when embedded? On a normal ShowItem navigation controlled by a Layout we could have a Layout specifically designed for embedding, which would just supress the sidebar, or place the SystemContent Blocks on the right hand side. The Item-specific actions could be placed in a drop down menu on top of the ShowItem-view, below the item's title.
So I don't see many reasons left to be working on getting system links out of the gallery space into the CMS-menu-space.
What do you think?
valiant
Joined: 2003-01-04
Posts: 32509
Posted: Sat, 2004-10-30 22:11
Quote:
- Site Admin, Login, Your Account, Logout will be moved to the header line
login, logout, your account -> disabled when embedded. site admin link either left in G2 or moved to the xaraya admin->gallery menu.
don't know what to think of the Systemcontent blocks in the sidebar. got to see it i guess. most of these systemcontent blocks should be blocks in the CMS and not in G2.
@item action links: the plan was to move all G2 menu links, whatever they are, system, item, ... to the menu of the CMS or to a block of the CMS.
IMO we don't want 2 menus, a CMS menu and a G2 menu, you should understand that as you've made a great effort to reduce the number of menu items etc.
finally, we need a CMS layout without the left sidebar. we move things like the imageblocks to optional CMS blocks, most CMS know the principle of blocks. navigation in a horizontal bar is fine. item actions could be placed in the layout, handed over to the CMS as a block or handed over to the CMS link by link.
baschny
Joined: 2003-01-04
Posts: 328
Posted: Sat, 2004-10-30 22:19
valiant, I like the idea of using the CMS' "block" concept to place gallery blocks! I am not sure how this should work, but this would be the most brilliant integration ever!!!
While rewriting the navigation, bharat and I also came to the conclusion that gallery itself (stand-alone) sometime in the future will need to give the admin some more finetuned control over the blocks and its placement, just like *nuke's (Order, positioning and visible/not-visible). Currently the only control you have is turn on/off the module that provides the blocks and hope you can control what content is displayed in that module's admin view (e.g. imageblock).
About the system links, if we don't have a sidebar in the embedded layout, I wouldn't care to have the item links for the current item displayed in a drop-down selectbox just like we have the subitem's links now. There is no need for the sidebar anymore. And there are no further links. Just the "Site Admin", which isn't that bad placed on the top right hand side of the breadcrumb, right?
I haven't had much time this week to work on g2, but will try to finish up the whole navigation mess next week.
valiant
Joined: 2003-01-04
Posts: 32509
Posted: Sun, 2004-10-31 13:32
baschny, would it be possible to process an arbitrary list of blocks in a single G2 request?
case A:
In a normal embedded G2 request, we need the HTML for the content, the HTML for the HTML head (both already implemented) and the HTML for an arbitrary list of blocks (random image, systemblocks, item actions).
case B:
But the G2 blocks should also be available in other areas of the CMS, i.e. on each page, show a random image from G2, or the systemblock summary of the cart module.
In this case, we don't need the content area HTML, just the block HTML and probably the HEAD html for the javascript and css.
At the moment, the request looks like this:
list($ret, $g2moddata) = GalleryEmbed::handleRequest($uid, $langCode);
$g2moddata['bodyHtml'] // has the body html, etc.
I propose something like this for case A:
list($ret, $g2moddata) = GalleryEmbed::handleRequest($uid, $langCode, array('body', 'head', 'randomimage', 'cart'));
// access the html like this...
$g2moddata['bodyHtml']
$g2moddata['headHtml']
$g2moddata['randomimageHtml']
$g2moddata['cartHtml']
And for case B: list($ret, $g2moddata) = GalleryEmbed::handleRequest($uid, $langCode, array('head', 'randomimage', 'newestimage'));
What do you think?
valiant
Joined: 2003-01-04
Posts: 32509
Posted: Sun, 2004-10-31 15:41
wait, that doesn't work on the CMS side.
i.e. in xaraya each block is called one after another. i could not make a single handlerequest call for all requested blocks.
i could assemble the information (query xaraya for all active G2 blocks) to make use of case B, but I guess it will be easier, if I just init G2 once and request each block separately like this,
case A:
GalleryEmbed::init(...);
GalleryEmbed::handlerequest($uid, $landCode);
// xaraya queries all blocks, and delegates some of the block requests to my gallery2 module
GalleryEmbed::handlerequest($uid, $langCode, 'blockname', $blockargs);
// actually, i don't need handlerequest() to handle blocks too, after GalleryEmbed::init() I have full access to the G2 API. but we could create a convenience function in GalleryEmbed.
mindless, if there's no CMS module in G2, how would you handle embedded G2 installations which still allow standalone mode? I mean, in this case, when you browse to G2 directly, you'll see login and register links and these links won't be redirects to the CMS login / register page.
G2 needs to store CMS login and register redirect urls and the capabilities which are set by the embedded mode for standalone mode too.
Either store these configs in config.php (don't like this idea), as core module plugin vars or create a CMS module for these configs.
baschny
Joined: 2003-01-04
Posts: 328
Posted: Sun, 2004-10-31 21:18
valiant, why are the $uid and $langCode parameters of handleRequest and not the init() call? I would imagine that other methods could make use of this information, even if we don't even call handleRequest(), so it might be sensitive to have this parameters as part of the init() process. (Maybe this has been discussed before and I am overseeing something). The uid and language shouldn't change throughout one embeding process.
About the blocks, after calling init() (and currently by having the active uid and language code stored in $gallery through handleRequest() ) its really very easy to just get a certain imageblock.
I've created a getSystemContent($moduleId) in embed.php to return the html content of a specific systemcontent of a certain module. Currently each module only provides a single block, after my navigation patch, each module will be able to provide more than one block, so this method would be changed to getSystemContent($moduleId, $blockName). Would that method be ok for you? Should I commit it?
valiant
Joined: 2003-01-04
Posts: 32509
Posted: Sun, 2004-10-31 21:40
baschny, currently, only the handlerequest needed to know who is logged in and what language is prefered.
the other methods of GalleryEmbed don't need this information.
But you are right, getSystemContent(), search(), ... will all need this information too. We could make $externalId and $languageCode _optional_ in GalleryEmbed::init() and make init() call _checkActiveUser($activeUserId).
And GalleryEmbed::handlerequest() would have no arguments.
What would getSystemContent('core') return?
baschny
Joined: 2003-01-04
Posts: 328
Posted: Sun, 2004-10-31 22:00
valiant, init already has a bunch of optional parameters ($initParams), simply add activeUser and langCode to them. Maybe we will also need a provision to init() to handle the case when it is called more than once. I don't know when and how the CMS' gathers block information, but it might be that you don't have a place to call a master initial init() before getting each block content.
The getSystemContent('core') currently is simply the language selector. After my - already well announced navigation-patch - this will be the 'languageSelector' block from core. So it isn't that interesting for embeding.
More interesting in future will be the SystemContent for "cart" (which will display the amount of items in cart or other details), for "search" (the gallery-search-box, if we don't use the CMS' own search box...), and of course "imageblock".
valiant
Joined: 2003-01-04
Posts: 32509
Posted: Sun, 2004-10-31 22:18
baschny, let's wait for mindless' point of view of moving externalId and languageCode to init, usually he decides more deliberately than i do
@more than one call to GalleryEmbed:
What I do in my xaraya gallery2 module: I have a init wrapper function which has a static variable $isInitiated, if false, it calls GalleryEmbed::init(), else it just returns true.
That way I would call GalleryEmbed::init() only once for each CMS page request even if mutliple blocks are requested.
The problem is that you should call GalleryEmbed::done() when you're finished with your G2 interactions. I do that, but do I have to call GalleryEmbed::init() again for a subsequent block when I called ::done() before?
Perhaps I should register GalleryEmbed::done() as a shutdown function
mindless
Joined: 2004-01-04
Posts: 8601
Posted: Wed, 2004-11-03 16:27
valiant wrote:
mindless, the imageblock module generates a sample url <?php @readfile('http://192.168.123.123/xaraya-0-9-10/index.php?module=gallery2?g2_view=imageblock:External&g2_blocks=randomImage&g2_show=title'); ?>which is slightly wrong. after embedURI it should start with & in this case. Do you use the GalleryUrlGenerator for this?
no, it didn't.. but it does now! thanks.
mindless
Joined: 2004-01-04
Posts: 8601
Posted: Wed, 2004-11-03 19:00
It does seem like those params could go with init().. the advantage of having extUserId in every init() call is if somebody writes special code that creates G2 items from the CMS app (ie possibly without visiting G2).. having extUserId in init() will ensure the items are created with the correct owner (and that the G2 session will have the right permissions).
Questions that come to mind:
1) Why do we need languageCode on every request? Seems to me like this value doesn't change often.. is there a better way to sync the selected language? I guess we check user on every request too.. maybe I just want the language check to be faster when it doesn't change (don't call getSupportedLanguageCode and setActiveLanguageCode).. we could check against a session value like we do for user.
2) Now that we're working with checking extUserId on each G2 request, do we want to continue to offer the alternate strategy? (of using login() method and not sending extUserId on each handleRequest) The advantage is if the G2 session somehow expires before the CMS session; with the extUserId strategy the new G2 session will get the right user logged in.. any other session data is lost, but having the right active user is much more important than other session data. With the login() strategy the new G2 session would be guest....
3) So, I still don't know the best strategy for G2 session expiration.. do we want to attempt some SID map and find a way for G2 to check if the CMS session is still valid? Alternative is to just make G2 session expiration fairly long so it will probably last as long as the CMS session.. but there's no guarantee; example, G2 session expiration = 2 weeks, CMS = 1 day. Day 1: user logins in and accesses G2; then every day for 3 weeks he accesses the CMS but does not visit G2.. the G2 session will expire, but CMS session still active. This is why I brought up question #2.. if we have a more reliable session expiration strategy then #2 is moot.
---
Different topic: UI structure / double sidebar.
Here are the types of data G2 has:
- system links
- system content blocks
- item links
- item summaries
- item details
It seems only system content blocks and item links for the top level item are content that we will normally be showing in a G2 sidebar. The question is, do we want to make the CMS app use embed apis to access any "sidebar" kind of data, or should we refactor the view/layout API such that it can return "sidebar" vs "body" content and the CMS can just drop the sidebar content in its own sidebar? Are we thinking in too detailed a case, the "sidebar"? Are there other layout considerations for fitting nicely into the CMS? (perhaps we want breadcrumb integration, are there other things?)
valiant
Joined: 2003-01-04
Posts: 32509
Posted: Thu, 2004-11-04 15:56
@languageCode:
Because it's the easiest solution. languageCode gets changed on user update in CMS or on session update in CMS. A user can change the preferred language in his profile or as in G2, a user / guest can change the session language somehow.
A user profile update calls a update hook function, that's fine.
But I have no means to get session variable updates in xaraya. That's why.
I'll try to convince the xaraya devs to add such an event. Maybe the overhead is too great and we won't get it...maybe there are just too few use cases.
You want to add externalLanguageCode to the G2 session? That would work too...
@login:
what's the advantage of login? less overhead on each G2 request, right? i don't remember exactly what we do in checkactiveuser(), but afaik it's just a check externalId vs. externalId from the cookie session which is nothing.
So we could definitely remove the login() method to create a session. but perhaps some people will find it easier using lgin() ?! no idea. We should emphasize that using init() with externalId on each request is the recommended method and login() is just a fallback for very rare cases.
@session expiration:
G2 session lifetime should be chosen reasonably high. What about 2 times the session life time of the CMS? I guess i could get this config var from xaraya...
@UI: perhaps i'll add answer to this topic at a later time.
valiant
Joined: 2003-01-04
Posts: 32509
Posted: Sat, 2004-11-06 14:38
How are other integrations progressing?
What about walkah and his Drupal integration?
Or spiderr and TikiPro?
I'd like to start documenting the whole process, a step by step guide for developers and admins, what functions are needed, sample functions etc.
I could use xaraya for the sample functions, but I guess other CMS may be a better choice for most functions because of the xaraya recursive role management to the flat G2 user/group management translation.
And we need some decisions for the links/blocks/UI issue plus, do we agree on the externalId -> init() change?
mindless
Joined: 2004-01-04
Posts: 8601
Posted: Tue, 2004-11-16 01:33
Ok, I've done some refactoring of layouts that will help us with some UI issues.. after the init() call and before handleRequest() you can now do: GalleryCapabilities::set('showSidebar', false);
This will instruct layouts using the standard sidebar to omit it.. this doesn't (currently) affect item/user/site admin views.
Now, how do we get sidebar content into the CMS sidebar? I've experimented with returning the smarty template data back from handleRequest.. (even though the sidebar wasn't shown, it still loaded the data needed to build the sidebar). I was able to see the "Site Admin" link in the xaraya sidebar by accessing this data from xaruserapi/getmenulinks.php. This can work for well-formed data like system links and item links.. any other sidebar content is tricky.. but maybe that's all we need?
valiant
Joined: 2003-01-04
Posts: 32509
Posted: Tue, 2004-11-16 08:07
Cool, thanks.
A xaraya user told me he wouldn't use the xaraya built-in menu.
So what I plan to do is putting all G2 sidebar menu links into the xaraya menu (actions, site admin, view cart).
and at the same time, i create xaraya blocks for the same G2 links plus all bigger sidebar stuff as imageblock, search area etc.
What's the sample code to get something like the item actions block?
mindless
Joined: 2004-01-04
Posts: 8601
Posted: Tue, 2004-11-16 16:42
So there are two different strategies here..
1) break up the returned html into more pieces.. "sidebar" could be a piece; cms can drop this in as a "block" on its own sidebar
or
2) provide access to the data used to build sidebar links, etc
While 2 can allow more seamless integration (like using xaraya getmenulinks) it would be hard to render all "sidebar" type of content that way.. we'd have to provide both links and blocks and a mechanism to render the blocks.
1 is easier to manage, but imposes a new restriction on the G2 view/layout mechanism... similar to how we might want to break up the header content into more distinct pieces.
mindless
Joined: 2004-01-04
Posts: 8601
Posted: Wed, 2004-11-17 20:11
I have an idea on #1... GalleryMain can check if "$layout.show.sidebar" template variable was set to false.. if so it can call "fetch" on sidebar.tpl (ie, render the sidebar and get the result in a variable) and return that content as $g2Data['sidebarHtml'].
This means if the cms doesn't change GalleryCapabilties::can('showSidebar') then the sidebar is rendered normally.. if the cms sets it to false then the sidebar won't be included in the $g2Data['bodyHtml'] content, but a separate $g2Data['sidebarHtml'] chunk is returned.. how does this sound?
mindless
Joined: 2004-01-04
Posts: 8601
Posted: Wed, 2004-11-17 23:07
Cool, tried this out and got the G2 sidebar inside the xaraya sidebar! (made a xarblocks/sidebar.php) Only snag was that the G2 theme (matrix theme) sets CSS for the gsSidebar as float:left and width:20%.. when the sidebar is shown in a different place these threw things off.. so in xaruser/main.php I added float:none !important and width:100% !important in a <style> tag and added it to the header block.
valiant
Joined: 2003-01-04
Posts: 32509
Posted: Thu, 2004-11-18 01:56
Cool stuff!
Could you send me the sidebar.php and commit everything you did not already commit that has something to do with this change?
That's really great, things are advancing!
And I'm sorry that I can't help more, I'm "currently" more than 150% busy with my semester thesis and other courses.
valiant
Joined: 2003-01-04
Posts: 32509
Posted: Sun, 2004-11-21 19:19
I'd like to offer the imageblock in xaraya in other areas than G2 too.
i.e. if a user browses to the main page of a website, he should see the newest addition to the gallery and other news.
sounds reasonable, right?
so i would like to use this code: <?php @readfile('http://xy.com/gallery2/main.php?g2_view=imageblock:External&g2_blocks=randomImage&g2_show=title'); ?>
now this user logs in, but still is on the main page. he would have the permission to see all items of G2, but the imageblock still shows only pictures for anonymous users, because G2 doesn't know that this user is logged in.
if we used the login event solution, this wouldn't be the case. but with our current login/session creation solution, this is an issue.
any ideas to solve this problem?
instead of the external imageblock url, i could use GalleryEmbed::init(), then a GalleryEmbed::getImageBlock(), but it must be as lightweight as the external imageblock.
Another thing, kinda related.
Didn't we want to move activeUserId / languageCode from GalleryEmbed::handleRequest to ::init()?
And also related:
We discussed about languageCode, if it really must be checked for each request, or not.
I already sync the site wide languageCode and the languageCode per user on site config and user data updates.
but i can't sync session languageCode updates. And we don't want to sync, with mindless' argument: we don't want to create G2 sessions for all CMS sessions, only a fraction of all CMS visitors visit G2 within the CMS.
So how to reduce the overhead?
Either let G2 check if the languageCode for the activeUser has changed / is another but the default or let the CMS do the work.
The CMS has an advantage: it doesn't have to translate the languageCode to a G2 languageCode.
So let the CMS check if the current languageCode differs from the default (user, site wide) languageCode and give G2 only then the languageCode, if it's different.
We leave languageCode in ::init() (or handleRequest()) but "integrators" are asked to do the check in the CMS and provide the languageCode only if it's not the default one.
t3rmin
Joined: 2004-12-04
Posts: 5
Posted: Sat, 2004-12-04 09:34
How's this stuff going? That demo site in your .sig seems to work. Any chance of some code? ;-)
valiant
Joined: 2003-01-04
Posts: 32509
Posted: Sat, 2004-12-04 12:09
i could give you the code, but it's not finished. give me 2-3 weeks or something to finish/clean it.
t3rmin
Joined: 2004-12-04
Posts: 5
Posted: Sun, 2004-12-05 07:21
Ok. Fair enough. Thanks for all your work on this.
I've been experimenting with Drupal CMS, but if I can integrate Gallery with Xaraya (fairly easily), I'll definitely go that route. After reading the EMBEDDING doc, I eventually got Gallery to wrap into Drupal satisfactorily. However, I had to mess with style sheets a ton and I haven't even tackled the login stuff yet...
mindless
Joined: 2004-01-04
Posts: 8601
Posted: Thu, 2004-12-09 18:21
cool, onto our 10th page of posts!
t3rmin, FYI walkah is also working on Drupal integration.
All, FYI--
I'm now making the changes we discussed a while back.. anyone currently using GalleryEmbed will need to make a few minor changes to the intg code.
Move activeUserId and language parameters from handleRequest() to init(). They are both optional, though activeUserId will usually be used (but you can call init() without it and call GalleryEmbed::checkActiveUser directly, before calling handleRequest).
Get rid of "option A" for session integration, ie calling login() at CMS login time. I've left in the login() method for completeness but added a comment that it isn't usually needed.
Rename 'layout' key in handleRequest return value to 'layoutData'
This change also fixed the language selection.. our old setActiveLanguageCode call was after the translator was init'ed so the change wouldn't take effect on that request (the request where it changed), but would be saved in the session so it would take effect on the next request. It now goes into effect on the first request.
Also a byproduct of the handleRequest change was there are no errors thrown in that method, so now it just returns $g2data directly instead of array(GalleryStatus, $g2data).
So the changes you'll need are moving activeUserId and activeLanguage parameters from handleRequest() call to members of the array passed to init(), and changing the return value from handleRequest from list ($ret, $g2data) to just $g2data. walkah will need to change 'layout' to 'layoutData' wherever you use that.[/]
mindless
Joined: 2004-01-04
Posts: 8601
Posted: Fri, 2004-12-10 16:29
i've also just changed GalleryUrlGenerator to append a / on relativeG2Path if needed, so now the parameter to GalleryEmbed::init() doesn't require a value ending in /
walkah
Joined: 2004-03-11
Posts: 5
Posted: Fri, 2004-12-10 16:33
t3rmin: I am indeed working on drupal + G2 integration. checkout my test site:
it's running drupal 4.5 & the latest (2004-12-09) CVS HEAD of gallery2. I will be making my drupal module available soon in the drupal contributions cvs repository.
valiant
Joined: 2003-01-04
Posts: 32509
Posted: Sat, 2004-12-11 23:15
mindless,
@sidebar:
i use GalleryCapabilities::set('showSidebar', false); in the xaraya xaruser/main.php and it works.
but when clicking on any link (but slideshow) in the sidebar (in the sidebar block in xaraya), the requested page doesn't obey the
GalleryCapabilities::set('showSidebar', false);
directive. i.e. click "add comment" or "edit item" or "search" in the sidebar.
Could you change that?
@register:
IMO we should have a register capability and disable it in GalleryEmbed::init().
@image blocks:
is there a similar way to the sidebarHtml code to get the image block?
something like that...
list ($ret, $data['sidebarHtml']) =
$template->fetch('gallery:templates/sidebar.tpl');
?
or how would i get the imageblock html from xaraya outside the gallery2 module?, i.e. to display a random image anywhere on the website.
it should obey the current uid and language. so, preferably I'd like to call GalleryEmbed::init(.....); then getImageblockHtml() or something like that.
mindless
Joined: 2004-01-04
Posts: 8601
Posted: Sat, 2004-12-11 23:22
I got a PM asking about the wordpress display-level integration I posted way back in september.. to make it compatible with the current GalleryEmbed api change this $ret = GalleryEmbed::init('gallery2.php', '../gallery2/'); to this $ret = GalleryEmbed::init(array('embedUri' => 'gallery2.php', 'relativeG2Path' => '../gallery2/'));
mindless
Joined: 2004-01-04
Posts: 8601
Posted: Sat, 2004-12-11 23:27
valiant wrote:
i use GalleryCapabilities::set('showSidebar', false); in the xaraya xaruser/main.php and it works.
but when clicking on any link (but slideshow) in the sidebar (in the sidebar block in xaraya), the requested page doesn't obey the
GalleryCapabilities::set('showSidebar', false);
directive. i.e. click "add comment" or "edit item" or "search" in the sidebar.
Could you change that?
not easily.. the showSidebar capability right now is only checked by layouts, not admin views (ItemAdmin/UserAdmin/SiteAdmin). do we need to expand this concept to other areas of G2 or can we live with a double sidebar in some of the admin views? (personally I think that's ok, but others may not)
Quote:
IMO we should have a register capability and disable it in GalleryEmbed::init().
I still disagree.
Quote:
@image blocks:
is there a similar way to the sidebarHtml code to get the image block?
something like that...
list ($ret, $data['sidebarHtml']) =
$template->fetch('gallery:templates/sidebar.tpl');
?
or how would i get the imageblock html from xaraya outside the gallery2 module?, i.e. to display a random image anywhere on the website.
it should obey the current uid and language. so, preferably I'd like to call GalleryEmbed::init(.....); then getImageblockHtml() or something like that.
imageblock already has imageblock:External.. does that help?
autys
Joined: 2004-12-07
Posts: 11
Posted: Sat, 2004-12-11 23:43
mindless wrote:
I got a PM asking about the wordpress display-level integration I posted way back in september.. to make it compatible with the current GalleryEmbed api change this $ret = GalleryEmbed::init('gallery2.php', '../gallery2/'); to this $ret = GalleryEmbed::init(array('embedUri' => 'gallery2.php', 'relativeG2Path' => '../gallery2/'));
Many thanks for the reply to the PM.. I've made the modifications above and I no longer get any error messges.. However, I'm not getting any images displayed.
Rather than using your gallery2.php file, I've created one that matches my site, and in the appropriate place added "<?php gallery2(); ?>
" All appears OK, but no gallery..
@register capability:
ok, thought about it, i agree, not needed. the admin has to disable the register module anyway for the visitors of the standalone view of an embedded G2.
@sidebar:
well, it just doesn't look very good when some parts have a sidebar outside the G2 content block and some have their sidebar in the content block, just very inconsistent.
how much work would it be to make this sidebar consistent in the whole G2, including all admin views?
valiant
Joined: 2003-01-04
Posts: 32509
Posted: Sun, 2004-12-12 00:34
@sidebar:
ok, maybe it's not that important. the greatest benefit of having the sidebar as a separate block in an embedded G2, is to have more space for the content, all the thumbnails or a big image.
for admin views, we don't need that much content. so, basically, it's ok to not have sidebarHtml for admin views.
but if it was feasible with only a few dev work, it would be quite nice.
mindless
Joined: 2004-01-04
Posts: 8601
Posted: Sun, 2004-12-12 00:56
valiant wrote:
for admin views, we don't need that much content. so, basically, it's ok to not have sidebarHtml for admin views.
but if it was feasible with only a few dev work, it would be quite nice.
agree 100%
autys wrote:
Rather than using your gallery2.php file, I've created one that matches my site, and in the appropriate place added "<?php gallery2(); ?>
" All appears OK, but no gallery..
the 'embedUri' value you pass to GalleryEmbed::init() needs to be the filename of the access point.. if it's not gallery2.php anymore then you need to update that value.
autys
Joined: 2004-12-07
Posts: 11
Posted: Sun, 2004-12-12 01:01
The content of the file is slightly different to yours, but the filename remains as gallery2.php, which matches the gallery2.php settings in the plugin directoy (as specified in youe message).
Si
autys
Joined: 2004-12-07
Posts: 11
Posted: Sun, 2004-12-12 01:03
Also, I do not have WP installed in the wordpress directory, it is directly in the root, so I've got:
Posts: 32509
mindless: i'd like to work on G2/xaraya on the weekend, but first, i need to know how we do this entityId<->externalId map :/ . already know where to put it (condition: fast access / translation from extId to entityId / userName)? that's a problem. we can't build a filesystem cache of this map that scales good. if we can add this externalId to the session data, we only need to query the map when a non anonymous user creates a new session and that's a good thing IMO.
if we want to filesystem cache this map, we should only map the last x and y most requested mappings if the total number of mappings exceeds a certain number, or is this too complicated for such a thing?
Posts: 8601
valiant, I am setting up the api so that we could support hint=null if we want.. however, how will that api allow you to process xaraya's user<->group changes? I think we should just not support that, or else xaraya's gallery2 module needs to handle it.. I don't want to add user<->group morphing in GalleryEmbed... what does it even mean to take a group of ten users and convert that group into a user? combine all permissions of those ten users and assign them to this new user??
Posts: 8601
Ok, added the map, core api, and updated GalleryEmbed to work with external ids instead of username/groupname.
valiant, I used your suggestion to put external user id in the G2 session, to make for an easier _checkActiveUser routine.. good idea! With that in place I didn't do any caching (yet) for the ExternalIdMap.. we can decide later if caching is needed.
Posts: 8601
on irc valiant made the good point that we could join to the Entity table to find entityType rather than store it in the map table.. after some discussion we decided to leave it in the map table. Three reasons:
1) embed code will still work even if some module changes the entity type for a user or group (even though from discussion above we don't think they should)
2) leaves open the hack possibility I mentioned above for supporting entityType string like 'xaraya-GalleryUser'
3) map query will be very fast (querying on primary key).. join would join primary key of 2 tables, so it probably wouldn't be too much slower though
Posts: 32509
I changed the gallery2 module to synchronize users and groups based on the new mapping rather than the former userName/groupName approach.
I still have to fix 1,2 bugs and wait for xaraya devs to agree on some minor roles module changes before I upload the new version of the xaraya gallery2 module.
The initial user/group import/export is still based on userNames/groupNames as there's no uid<->entityId at the time of this initial synchronization. This makes the import/export code rather bloated, but the rest, the create, update, delete hooks are quite short in code.
I think it's a good idea to check on $gallery->setConfig('mode.embed.only', true); during xaraya gallery2 module configuration/import/export time. It's like the G2 maintenance mode i proposed, it ensures that all G2 interactions run through the CMS and the CMS blocks all G2 requests until the gallery2 module has been configured. Having no changes in G2 during the user import/export is a very good thing
Posts: 32509
mindless, it would be great if you could up with one of your ingenious over night ideas/implementations for the menu links ;)
We need also a template without menu/search block/imageblock.
(The whole left column).
Today, I filed another 2 xaraya bugs. One in the event system and yet another roles module bug. This really sucks.
Posts: 2
Hy EveryBody..
I've installed Gallery2 via CVS and works perfectly; after i've installed Xaraya
and i've downloaded the g2 module and installed it in xaraya.
When i go to set the relative path to my gallery2 path, i find this error:
Could not login in G2. Here is the error message from G2: <br /> [Error (ERROR_STORAGE_FAILURE)<UL><LI><B>in</B> C:\Program Files\Apache Group\Apache2\htdocs\prova\gallery2\modules\core\classes\GalleryStorage\DatabaseStorage.class <B>at line</B> 720 (gallerystatus::error) <LI><B>in</B> C:\Program Files\Apache Group\Apache2\htdocs\prova\gallery2\modules\core\classes\GalleryStorage.class <B>at line</B> 220 (mysqldatabasestorage::search) <LI><B>in</B> C:\Program Files\Apache Group\Apache2\htdocs\prova\gallery2\modules\core\classes\Gallery.class <B>at line</B> 176 (gallerystorage::search) <LI><B>in</B> C:\Program Files\Apache Group\Apache2\htdocs\prova\gallery2\modules\core\classes\helpers\GalleryEntityHelper_simple.class <B>at line</B> 131 (gallery::search) <LI><B>in</B> C:\Program Files\Apache Group\Apache2\htdocs\prova\gallery2\modules\core\classes\GalleryCoreApi.class <B>at line</B> 2036 (galleryentityhelper_simple::loadentitybyexternalid) <LI><B>in</B> C:\Program Files\Apache Group\Apache2\htdocs\prova\gallery2\embed.php <B>at line</B> 179 (gallerycoreapi::loadentitybyexternalid) <LI><B>in</B> C:\Program Files\Apache Group\Apache2\htdocs\modules\gallery2\xargallery2helper.php <B>at line</B> 402 (galleryembed::login) <LI><B>in</B> C:\Program Files\Apache Group\Apache2\htdocs\modules\gallery2\xaradmin\updateconfig.php <B>at line</B> 86 (xargallery2helper::g2login) <LI><B>in</B> C:\Program Files\Apache Group\Apache2\htdocs\includes\xarMod.php <B>at line</B> 855<LI><B>in</B> C:\Program Files\Apache Group\Apache2\htdocs\index.php <B>at line</B> 82<LI><B>in</B> C:\Program Files\Apache Group\Apache2\htdocs\index.php <B>at line</B> 150</UL>]
So i can't install gallery2 module.
Can help me??
Thanks..
Eugenio.
Posts: 8601
How recently did you run the G2 installer? Make sure you have a g2_ExternalIdMap table in your G2 db.. if not, reinstall G2 with latest cvs.
Posts: 32509
darkice,
the current xaraya gallery2 module in my signature is obsolete, it still synchronizes based on usernames.
a new xaraya gallery2 module compatible with the current G2 release is actually ready, but there are still issues with xaraya. and i haven't tested it thouroughly.
give me another 2-3 days for a more bug free module.
Posts: 2
I've reinstalled G2 with latest cvs and now i can see the table g2_ExternalIdMap.
Unfortunately i've found the some problem (the list of errors).
So i'm waiting for the new module release..
Regards.
Posts: 32509
mindless, the imageblock module generates a sample url
<?php @readfile('http://192.168.123.123/xaraya-0-9-10/index.php?module=gallery2?g2_view=imageblock:External&g2_blocks=randomImage&g2_show=title'); ?>which is slightly wrong. after embedURI it should start with & in this case. Do you use the GalleryUrlGenerator for this?However, I'd like to include some blocks in xaraya. Should I use it like
$data['imageblock'] = @readfile(xarModGetVar('gallery2','g2.basefile') . '&g2_view=imageblock:External&g2_blocks=randomImage&g2_show=title');
?
I think it would be better to call init the G2 API and then access the imageblock API, right?
Get menu links still has the top priority though...
Posts: 328
If you are talking about the "navigation" links on the sidebar (called SystemLinks), be aware that after my navigation patch (to be released soon), most (all) of them will be gone:
- Site Admin, Login, Your Account, Logout will be moved to the header line
- "View Cart" and "Members list" will be placed on its own SystemContent Blocks in the sidebar, together with more module information (e.g. items in cart and total number of members)
The sidebar on the left will be left just with a bunch of SystemContent's. We will make very sparingly use of SystemLinks, as they will be placed in a new horizontal menu on the top bar (to the right of the breadcrumb). The only left "links" in the sidebar are the "current items's action", which is generated by our matrix layout.
So now the question is: What SystemContent's do we need when embedded? On a normal ShowItem navigation controlled by a Layout we could have a Layout specifically designed for embedding, which would just supress the sidebar, or place the SystemContent Blocks on the right hand side. The Item-specific actions could be placed in a drop down menu on top of the ShowItem-view, below the item's title.
So I don't see many reasons left to be working on getting system links out of the gallery space into the CMS-menu-space.
What do you think?
Posts: 32509
login, logout, your account -> disabled when embedded. site admin link either left in G2 or moved to the xaraya admin->gallery menu.
don't know what to think of the Systemcontent blocks in the sidebar. got to see it i guess. most of these systemcontent blocks should be blocks in the CMS and not in G2.
@item action links: the plan was to move all G2 menu links, whatever they are, system, item, ... to the menu of the CMS or to a block of the CMS.
IMO we don't want 2 menus, a CMS menu and a G2 menu, you should understand that as you've made a great effort to reduce the number of menu items etc.
finally, we need a CMS layout without the left sidebar. we move things like the imageblocks to optional CMS blocks, most CMS know the principle of blocks. navigation in a horizontal bar is fine. item actions could be placed in the layout, handed over to the CMS as a block or handed over to the CMS link by link.
Posts: 328
valiant, I like the idea of using the CMS' "block" concept to place gallery blocks! I am not sure how this should work, but this would be the most brilliant integration ever!!!
While rewriting the navigation, bharat and I also came to the conclusion that gallery itself (stand-alone) sometime in the future will need to give the admin some more finetuned control over the blocks and its placement, just like *nuke's (Order, positioning and visible/not-visible). Currently the only control you have is turn on/off the module that provides the blocks and hope you can control what content is displayed in that module's admin view (e.g. imageblock).
About the system links, if we don't have a sidebar in the embedded layout, I wouldn't care to have the item links for the current item displayed in a drop-down selectbox just like we have the subitem's links now. There is no need for the sidebar anymore. And there are no further links. Just the "Site Admin", which isn't that bad placed on the top right hand side of the breadcrumb, right?
I haven't had much time this week to work on g2, but will try to finish up the whole navigation mess next week.
Posts: 32509
baschny, would it be possible to process an arbitrary list of blocks in a single G2 request?
case A:
In a normal embedded G2 request, we need the HTML for the content, the HTML for the HTML head (both already implemented) and the HTML for an arbitrary list of blocks (random image, systemblocks, item actions).
case B:
But the G2 blocks should also be available in other areas of the CMS, i.e. on each page, show a random image from G2, or the systemblock summary of the cart module.
In this case, we don't need the content area HTML, just the block HTML and probably the HEAD html for the javascript and css.
At the moment, the request looks like this:
I propose something like this for case A:
list($ret, $g2moddata) = GalleryEmbed::handleRequest($uid, $langCode, array('body', 'head', 'randomimage', 'cart')); // access the html like this... $g2moddata['bodyHtml'] $g2moddata['headHtml'] $g2moddata['randomimageHtml'] $g2moddata['cartHtml']And for case B:
list($ret, $g2moddata) = GalleryEmbed::handleRequest($uid, $langCode, array('head', 'randomimage', 'newestimage'));What do you think?
Posts: 32509
wait, that doesn't work on the CMS side.
i.e. in xaraya each block is called one after another. i could not make a single handlerequest call for all requested blocks.
i could assemble the information (query xaraya for all active G2 blocks) to make use of case B, but I guess it will be easier, if I just init G2 once and request each block separately like this,
case A:
GalleryEmbed::init(...);
GalleryEmbed::handlerequest($uid, $landCode);
// xaraya queries all blocks, and delegates some of the block requests to my gallery2 module
GalleryEmbed::handlerequest($uid, $langCode, 'blockname', $blockargs);
// actually, i don't need handlerequest() to handle blocks too, after GalleryEmbed::init() I have full access to the G2 API. but we could create a convenience function in GalleryEmbed.
case B:
GalleryEmbed::init(...);
GalleryEmbed::handlerequest($uid, $langCode, 'blockname_1', $blockargs);
...
GalleryEmbed::handlerequest($uid, $langCode, 'blockname_2', $blockargs);
...
Posts: 32509
mindless, if there's no CMS module in G2, how would you handle embedded G2 installations which still allow standalone mode? I mean, in this case, when you browse to G2 directly, you'll see login and register links and these links won't be redirects to the CMS login / register page.
G2 needs to store CMS login and register redirect urls and the capabilities which are set by the embedded mode for standalone mode too.
Either store these configs in config.php (don't like this idea), as core module plugin vars or create a CMS module for these configs.
Posts: 328
valiant, why are the $uid and $langCode parameters of handleRequest and not the init() call? I would imagine that other methods could make use of this information, even if we don't even call handleRequest(), so it might be sensitive to have this parameters as part of the init() process. (Maybe this has been discussed before and I am overseeing something). The uid and language shouldn't change throughout one embeding process.
About the blocks, after calling init() (and currently by having the active uid and language code stored in $gallery through handleRequest() ) its really very easy to just get a certain imageblock.
I've created a getSystemContent($moduleId) in embed.php to return the html content of a specific systemcontent of a certain module. Currently each module only provides a single block, after my navigation patch, each module will be able to provide more than one block, so this method would be changed to getSystemContent($moduleId, $blockName). Would that method be ok for you? Should I commit it?
Posts: 32509
baschny, currently, only the handlerequest needed to know who is logged in and what language is prefered.
the other methods of GalleryEmbed don't need this information.
But you are right, getSystemContent(), search(), ... will all need this information too. We could make $externalId and $languageCode _optional_ in GalleryEmbed::init() and make init() call _checkActiveUser($activeUserId).
And GalleryEmbed::handlerequest() would have no arguments.
What would getSystemContent('core') return?
Posts: 328
valiant, init already has a bunch of optional parameters ($initParams), simply add activeUser and langCode to them. Maybe we will also need a provision to init() to handle the case when it is called more than once. I don't know when and how the CMS' gathers block information, but it might be that you don't have a place to call a master initial init() before getting each block content.
The getSystemContent('core') currently is simply the language selector. After my - already well announced navigation-patch - this will be the 'languageSelector' block from core. So it isn't that interesting for embeding.
More interesting in future will be the SystemContent for "cart" (which will display the amount of items in cart or other details), for "search" (the gallery-search-box, if we don't use the CMS' own search box...), and of course "imageblock".
Posts: 32509
baschny, let's wait for mindless' point of view of moving externalId and languageCode to init, usually he decides more deliberately than i do
@more than one call to GalleryEmbed:
What I do in my xaraya gallery2 module: I have a init wrapper function which has a static variable $isInitiated, if false, it calls GalleryEmbed::init(), else it just returns true.
That way I would call GalleryEmbed::init() only once for each CMS page request even if mutliple blocks are requested.
The problem is that you should call GalleryEmbed::done() when you're finished with your G2 interactions. I do that, but do I have to call GalleryEmbed::init() again for a subsequent block when I called ::done() before?
Perhaps I should register GalleryEmbed::done() as a shutdown function
Posts: 8601
no, it didn't.. but it does now! thanks.
Posts: 8601
It does seem like those params could go with init().. the advantage of having extUserId in every init() call is if somebody writes special code that creates G2 items from the CMS app (ie possibly without visiting G2).. having extUserId in init() will ensure the items are created with the correct owner (and that the G2 session will have the right permissions).
Questions that come to mind:
1) Why do we need languageCode on every request? Seems to me like this value doesn't change often.. is there a better way to sync the selected language? I guess we check user on every request too.. maybe I just want the language check to be faster when it doesn't change (don't call getSupportedLanguageCode and setActiveLanguageCode).. we could check against a session value like we do for user.
2) Now that we're working with checking extUserId on each G2 request, do we want to continue to offer the alternate strategy? (of using login() method and not sending extUserId on each handleRequest) The advantage is if the G2 session somehow expires before the CMS session; with the extUserId strategy the new G2 session will get the right user logged in.. any other session data is lost, but having the right active user is much more important than other session data. With the login() strategy the new G2 session would be guest....
3) So, I still don't know the best strategy for G2 session expiration.. do we want to attempt some SID map and find a way for G2 to check if the CMS session is still valid? Alternative is to just make G2 session expiration fairly long so it will probably last as long as the CMS session.. but there's no guarantee; example, G2 session expiration = 2 weeks, CMS = 1 day. Day 1: user logins in and accesses G2; then every day for 3 weeks he accesses the CMS but does not visit G2.. the G2 session will expire, but CMS session still active. This is why I brought up question #2.. if we have a more reliable session expiration strategy then #2 is moot.
---
Different topic: UI structure / double sidebar.
Here are the types of data G2 has:
- system links
- system content blocks
- item links
- item summaries
- item details
It seems only system content blocks and item links for the top level item are content that we will normally be showing in a G2 sidebar. The question is, do we want to make the CMS app use embed apis to access any "sidebar" kind of data, or should we refactor the view/layout API such that it can return "sidebar" vs "body" content and the CMS can just drop the sidebar content in its own sidebar? Are we thinking in too detailed a case, the "sidebar"? Are there other layout considerations for fitting nicely into the CMS? (perhaps we want breadcrumb integration, are there other things?)
Posts: 32509
@languageCode:
Because it's the easiest solution. languageCode gets changed on user update in CMS or on session update in CMS. A user can change the preferred language in his profile or as in G2, a user / guest can change the session language somehow.
A user profile update calls a update hook function, that's fine.
But I have no means to get session variable updates in xaraya. That's why.
I'll try to convince the xaraya devs to add such an event. Maybe the overhead is too great and we won't get it...maybe there are just too few use cases.
You want to add externalLanguageCode to the G2 session? That would work too...
@login:
what's the advantage of login? less overhead on each G2 request, right? i don't remember exactly what we do in checkactiveuser(), but afaik it's just a check externalId vs. externalId from the cookie session which is nothing.
So we could definitely remove the login() method to create a session. but perhaps some people will find it easier using lgin() ?! no idea. We should emphasize that using init() with externalId on each request is the recommended method and login() is just a fallback for very rare cases.
@session expiration:
G2 session lifetime should be chosen reasonably high. What about 2 times the session life time of the CMS? I guess i could get this config var from xaraya...
@UI: perhaps i'll add answer to this topic at a later time.
Posts: 32509
How are other integrations progressing?
What about walkah and his Drupal integration?
Or spiderr and TikiPro?
I'd like to start documenting the whole process, a step by step guide for developers and admins, what functions are needed, sample functions etc.
I could use xaraya for the sample functions, but I guess other CMS may be a better choice for most functions because of the xaraya recursive role management to the flat G2 user/group management translation.
And we need some decisions for the links/blocks/UI issue plus, do we agree on the externalId -> init() change?
Posts: 8601
Ok, I've done some refactoring of layouts that will help us with some UI issues.. after the init() call and before handleRequest() you can now do: GalleryCapabilities::set('showSidebar', false);
This will instruct layouts using the standard sidebar to omit it.. this doesn't (currently) affect item/user/site admin views.
Now, how do we get sidebar content into the CMS sidebar? I've experimented with returning the smarty template data back from handleRequest.. (even though the sidebar wasn't shown, it still loaded the data needed to build the sidebar). I was able to see the "Site Admin" link in the xaraya sidebar by accessing this data from xaruserapi/getmenulinks.php. This can work for well-formed data like system links and item links.. any other sidebar content is tricky.. but maybe that's all we need?
Posts: 32509
Cool, thanks.
A xaraya user told me he wouldn't use the xaraya built-in menu.
So what I plan to do is putting all G2 sidebar menu links into the xaraya menu (actions, site admin, view cart).
and at the same time, i create xaraya blocks for the same G2 links plus all bigger sidebar stuff as imageblock, search area etc.
What's the sample code to get something like the item actions block?
Posts: 8601
So there are two different strategies here..
1) break up the returned html into more pieces.. "sidebar" could be a piece; cms can drop this in as a "block" on its own sidebar
or
2) provide access to the data used to build sidebar links, etc
While 2 can allow more seamless integration (like using xaraya getmenulinks) it would be hard to render all "sidebar" type of content that way.. we'd have to provide both links and blocks and a mechanism to render the blocks.
1 is easier to manage, but imposes a new restriction on the G2 view/layout mechanism... similar to how we might want to break up the header content into more distinct pieces.
Posts: 8601
I have an idea on #1... GalleryMain can check if "$layout.show.sidebar" template variable was set to false.. if so it can call "fetch" on sidebar.tpl (ie, render the sidebar and get the result in a variable) and return that content as $g2Data['sidebarHtml'].
This means if the cms doesn't change GalleryCapabilties::can('showSidebar') then the sidebar is rendered normally.. if the cms sets it to false then the sidebar won't be included in the $g2Data['bodyHtml'] content, but a separate $g2Data['sidebarHtml'] chunk is returned.. how does this sound?
Posts: 8601
Cool, tried this out and got the G2 sidebar inside the xaraya sidebar! (made a xarblocks/sidebar.php) Only snag was that the G2 theme (matrix theme) sets CSS for the gsSidebar as float:left and width:20%.. when the sidebar is shown in a different place these threw things off.. so in xaruser/main.php I added float:none !important and width:100% !important in a <style> tag and added it to the header block.
Posts: 32509
Cool stuff!
Could you send me the sidebar.php and commit everything you did not already commit that has something to do with this change?
That's really great, things are advancing!
And I'm sorry that I can't help more, I'm "currently" more than 150% busy with my semester thesis and other courses.
Posts: 32509
I'd like to offer the imageblock in xaraya in other areas than G2 too.
i.e. if a user browses to the main page of a website, he should see the newest addition to the gallery and other news.
sounds reasonable, right?
so i would like to use this code:
<?php @readfile('http://xy.com/gallery2/main.php?g2_view=imageblock:External&g2_blocks=randomImage&g2_show=title'); ?>now this user logs in, but still is on the main page. he would have the permission to see all items of G2, but the imageblock still shows only pictures for anonymous users, because G2 doesn't know that this user is logged in.
if we used the login event solution, this wouldn't be the case. but with our current login/session creation solution, this is an issue.
any ideas to solve this problem?
instead of the external imageblock url, i could use GalleryEmbed::init(), then a GalleryEmbed::getImageBlock(), but it must be as lightweight as the external imageblock.
Another thing, kinda related.
Didn't we want to move activeUserId / languageCode from GalleryEmbed::handleRequest to ::init()?
And also related:
We discussed about languageCode, if it really must be checked for each request, or not.
I already sync the site wide languageCode and the languageCode per user on site config and user data updates.
but i can't sync session languageCode updates. And we don't want to sync, with mindless' argument: we don't want to create G2 sessions for all CMS sessions, only a fraction of all CMS visitors visit G2 within the CMS.
So how to reduce the overhead?
Either let G2 check if the languageCode for the activeUser has changed / is another but the default or let the CMS do the work.
The CMS has an advantage: it doesn't have to translate the languageCode to a G2 languageCode.
So let the CMS check if the current languageCode differs from the default (user, site wide) languageCode and give G2 only then the languageCode, if it's different.
We leave languageCode in ::init() (or handleRequest()) but "integrators" are asked to do the check in the CMS and provide the languageCode only if it's not the default one.
Posts: 5
How's this stuff going? That demo site in your .sig seems to work. Any chance of some code? ;-)
Posts: 32509
i could give you the code, but it's not finished. give me 2-3 weeks or something to finish/clean it.
Posts: 5
Ok. Fair enough. Thanks for all your work on this.
I've been experimenting with Drupal CMS, but if I can integrate Gallery with Xaraya (fairly easily), I'll definitely go that route. After reading the EMBEDDING doc, I eventually got Gallery to wrap into Drupal satisfactorily. However, I had to mess with style sheets a ton and I haven't even tackled the login stuff yet...
Posts: 8601
cool, onto our 10th page of posts!
t3rmin, FYI walkah is also working on Drupal integration.
All, FYI--
I'm now making the changes we discussed a while back.. anyone currently using GalleryEmbed will need to make a few minor changes to the intg code.
This change also fixed the language selection.. our old setActiveLanguageCode call was after the translator was init'ed so the change wouldn't take effect on that request (the request where it changed), but would be saved in the session so it would take effect on the next request. It now goes into effect on the first request.
Also a byproduct of the handleRequest change was there are no errors thrown in that method, so now it just returns $g2data directly instead of array(GalleryStatus, $g2data).
So the changes you'll need are moving activeUserId and activeLanguage parameters from handleRequest() call to members of the array passed to init(), and changing the return value from handleRequest from list ($ret, $g2data) to just $g2data. walkah will need to change 'layout' to 'layoutData' wherever you use that.[/]
Posts: 8601
i've also just changed GalleryUrlGenerator to append a / on relativeG2Path if needed, so now the parameter to GalleryEmbed::init() doesn't require a value ending in /
Posts: 5
t3rmin: I am indeed working on drupal + G2 integration. checkout my test site:
http://aurora.walkah.net/drupalgallery
it's running drupal 4.5 & the latest (2004-12-09) CVS HEAD of gallery2. I will be making my drupal module available soon in the drupal contributions cvs repository.
Posts: 32509
mindless,
@sidebar:
i use GalleryCapabilities::set('showSidebar', false); in the xaraya xaruser/main.php and it works.
but when clicking on any link (but slideshow) in the sidebar (in the sidebar block in xaraya), the requested page doesn't obey the
GalleryCapabilities::set('showSidebar', false);
directive. i.e. click "add comment" or "edit item" or "search" in the sidebar.
Could you change that?
@register:
IMO we should have a register capability and disable it in GalleryEmbed::init().
@image blocks:
is there a similar way to the sidebarHtml code to get the image block?
something like that...
list ($ret, $data['sidebarHtml']) =
$template->fetch('gallery:templates/sidebar.tpl');
?
or how would i get the imageblock html from xaraya outside the gallery2 module?, i.e. to display a random image anywhere on the website.
it should obey the current uid and language. so, preferably I'd like to call GalleryEmbed::init(.....); then getImageblockHtml() or something like that.
Posts: 8601
I got a PM asking about the wordpress display-level integration I posted way back in september.. to make it compatible with the current GalleryEmbed api change this
$ret = GalleryEmbed::init('gallery2.php', '../gallery2/');to this$ret = GalleryEmbed::init(array('embedUri' => 'gallery2.php', 'relativeG2Path' => '../gallery2/'));Posts: 8601
not easily.. the showSidebar capability right now is only checked by layouts, not admin views (ItemAdmin/UserAdmin/SiteAdmin). do we need to expand this concept to other areas of G2 or can we live with a double sidebar in some of the admin views? (personally I think that's ok, but others may not)
I still disagree.
imageblock already has imageblock:External.. does that help?
Posts: 11
Many thanks for the reply to the PM.. I've made the modifications above and I no longer get any error messges.. However, I'm not getting any images displayed.
Rather than using your gallery2.php file, I've created one that matches my site, and in the appropriate place added "<?php gallery2(); ?>
" All appears OK, but no gallery..
www.rambozotheclown.co.uk/gallery2.php
Si
Posts: 32509
@register capability:
ok, thought about it, i agree, not needed. the admin has to disable the register module anyway for the visitors of the standalone view of an embedded G2.
@sidebar:
well, it just doesn't look very good when some parts have a sidebar outside the G2 content block and some have their sidebar in the content block, just very inconsistent.
how much work would it be to make this sidebar consistent in the whole G2, including all admin views?
Posts: 32509
@sidebar:
ok, maybe it's not that important. the greatest benefit of having the sidebar as a separate block in an embedded G2, is to have more space for the content, all the thumbnails or a big image.
for admin views, we don't need that much content. so, basically, it's ok to not have sidebarHtml for admin views.
but if it was feasible with only a few dev work, it would be quite nice.
Posts: 8601
agree 100%
the 'embedUri' value you pass to GalleryEmbed::init() needs to be the filename of the access point.. if it's not gallery2.php anymore then you need to update that value.
Posts: 11
The content of the file is slightly different to yours, but the filename remains as gallery2.php, which matches the gallery2.php settings in the plugin directoy (as specified in youe message).
Si
Posts: 11
Also, I do not have WP installed in the wordpress directory, it is directly in the root, so I've got:
Posts: 8601
um, wouldn't that make relativeG2Path be 'gallery2/' ??
Posts: 11
I've tried that too (That's what I thought it should be).. still nothing
Posts: 105
FYI ... I did start integrating G2 into phpBB 2.1.x. I will come out with some code soon.