CoreAPI etc help please?
Dayo
Joined: 2005-11-04
Posts: 1642 |
Posted: Sun, 2007-10-21 18:40 |
Hi. This is my first foray into heavy stuff (for me at least) I want to make a call to the CoreAPI and I have actually figured out what to do. My problem is that the function requires the item details (understandable) but I want to apply the function to only non Album items so I need a way to figure out if an item is an album or not and fairly clueless. I was thinking of something like this (in NormalLanguageCode) foreach ($items as $item) { <<< looping through all items if (!(GalleryUtilities::isA($item, 'Album'))){ <<< checking it is not an album $ret = GalleryCoreApi::somefunction($item, $myVar1, $myVar2, $myVar3); <<< applying desired function if ($ret) { return $ret->wrap(__FILE__, __LINE__); } } } Anyone please help vet / correct the code? Thanks . |
|
Posts: 32509
the correct way to differentiate data items from container (album) items is:
$item->getCanContainChildren(). if true, it's an album.
if you further want to restrict it to real albums and filter out dynamic albums, use:
GalleryUtilitites::isA($item, 'GalleryAlbumItem').
--------------
Documentation: Support / Troubleshooting | Installation, Upgrade, Configuration and Usage
Posts: 1642
Thanks
So this should work then (sorry not sure)
.
Gallery version = 2.2.2
Default theme = PGtheme 1.3.0
Web Site: dakanji.com
Posts: 32509
yes...why not just test it?
btw: $ret->wrap() is deprecated since g2.1. just do: return $ret;
--------------
Documentation: Support / Troubleshooting | Installation, Upgrade, Configuration and Usage
Posts: 1642
I have been testing...a lot lol.
I think I know where I am going wrong.
I have been doing
but I think there should be something like
Any tips on those first two lines?
On $ret, how about "return array($ret->wrap(__FILE__, __LINE__), null);"?
Thanks for your assistance.
.
Gallery version = 2.2.2
Default theme = PGtheme 1.3.0
Web Site: dakanji.com
Posts: 32509
you shouldn't have any code that needs to iterate over all g2 items. you could be dealing with a million items. try to scale things down.
anyhow, please take a look at docs -> development -> api -> core api.
all methods are listed there.
@$ret:
replace all $ret->wrap(...) with $ret.
this is documented at docs -> development -> api -> changes between 2.1 and 2.2.
--------------
Documentation: Support / Troubleshooting | Installation, Upgrade, Configuration and Usage
Posts: 1642
Oops! You're right. I only have about 100 or so items but yes, some galleries might be huge.
Wish there was a way to directly address data items without looping through elements.
I'll have a read of the docs.
Cheers!
.
Gallery version = 2.2.2
Default theme = PGtheme 1.3.0
Web Site: dakanji.com
Posts: 1642
OK I found a way to do it.
I wanted to split the zencart link from gallery which is currently one link for bought adding items and viewing the cart into two separate items and to structure a more reasonable default permissions setup.
The current setup is to grant permissions to everybody to add / view for all items using
This obviously sets the permission for the main gallery and applies it to all the children and has the following issues
1) No one will be adding the whole gallery to a cart (and they can't anyway even if they wanted too...see 2 below)
2) The module is set up only to work when the link is clicked from a DataItem and will simply return anyone trying on an album page back to the same page.
I split the permissions etc into two and wanted to set the default up so that people could view carts from every page but not get get a non working link for adding items on album pages.
After your warning about huge galleries, I thought about adding the permissions for both for everybody by default as before (no looping) and then removing the permissions for adding items from album items (looping involved) on the premise that there will always be fewer album items than data items pages and ZenCart will not be a viable option for someone with 10's of '000s of items anyway. In any case, this will only run once when the module is installed by such a person and I will add a warning to the Readme File
After rooting through the docs, I came up with:
This way, the permissions are set up properly by default.
I think this is a reasonable approach but just wanted to know if this level of looping appears ok given the things I mentioned in your opinion before I put out into the wild.
A last question. The module has the following
Do I need to change this when I change the "$ret" thing as I noticed the change was at 7.4 (not sure what that means).
Thanks for your time.
.
Gallery version = 2.2.2
Default theme = PGtheme 1.3.0
Web Site: dakanji.com
Posts: 32509
you can leave the ->wrap() stuff if you want to target gallery 2.1 installations as well. just make sure you don't use any other feature that isn't in gallery 2.1.
(= either test with gallery g2.1 or review the changes since 2.1 at development -> api -> changes between 2.1 and 2.2).
$ret will be gone in gallery 2.4 anyway, so i wouldn't worry about ->wrap(). shouldn't have pointed your attention on that, sorry.
--------------
Documentation: Support / Troubleshooting | Installation, Upgrade, Configuration and Usage