Would be useful to know when a visitor or bot:
- Clicks on an item link to view item details
- Visits an item detail page
One use case would be:
- Record/log item detail link views or link clicks for later reporting and analysis and visitor analytics
Implementation should allow modules to implement an 'amazon_store_detail_click' and 'amazon_store_detail_page_view' hook handlers.
The 'amazon_store_detail_page_view' hook should allow redirection to another URL and specify the HTTP redirection status code (301, etc). In other words, the hook implementation can override the default behaviour, which is to load the default item details page.
Comments
Comment #1
rfayI kind of think this should be handled already by the Drupal stats module or by webserver logs?
Comment #2
mcurry commentedWell, perhaps in the use case I listed. I have another use case that isn't handled by the current Drupal stats. I'd like to record visited ASINS and do some background processing on all recorded ASIN visits. I *can* do that by examining the visitor logs, but redirecting to another page instead of the detail page isn't so easy (I suppose I could use lower-level Drupal hooks for that).
Let me think about this for a while. Marking as postponed pending more info.
Comment #3
mcurry commentedChanging title to reflect what I *really* wanted. :D
Here's what I'm after.
In the simplest case, let's say I want to generate concise logs about the ASINs users look up on my Amazon Store. Sure, I could scour log files, intercept page views and examine URLs, etc. but why should I have to go through all that trouble?
For a more complex case, let's say I want to build an Amazon Store contrib module that collects info on all Amazon item lookups through the Amazon Store module.
Why would I want to do that?
I'd like to gather and analyze information that's contained in the item lookup response, for later use in the site's Amazon store. Let's say (for example) I want to build a dynamic store that shows related categories and products in a more intelligent way (or at least, different from the way Amazon's related products works).
One way for me to do this is to analyze certain information returned from the successful ItemLookup operation when it is retrieved from the Amazon server. (Yes, I know about the Amazon guidelines on caching data; I'm not going to violate their guidelines and neither should you.)
But, I can't do this easily without a notification when the ItemLookup operation succeeds. I *could* scour the cache table periodically, looking for new entries, but that's a hack and grossly inefficient. Much easier to receive a notification when the item retrieval takes place. And it's very simple to implement in
amazon_store_get_item_data(). Just add a call tomodule_invoke_all():Works like a charm.
I don't see this as a major performance or reliability issue unless hook implementers are careless. But that's the case with all hook implementations, isn't it?
6.x-2.x-dev patch attached.
Comment #4
rfayYou're only giving them a shot at the data when it's not cached... Is that what you want?
I think this should be OK as a basic approach.
Comment #5
mcurry commented@rfay:
Yes, that's exactly what I am proposing, because I can see a distinct use case where clients only want to know about new lookups as they occur (as is the case in my store).
I can see a use case for getting a callback on every lookup whether cached or not, but that could be a separate callback.
I anticipate (and will propose) additional callbacks for the other API lookups, which will be described in separate issue(s); this was my first cut since I have a direct need for this one now.
Comment #6
mcurry commented@rfay: Any objections to me committing this mod? I'll have to port it to the D7 branch...
(I'm itching to try out my new commit access :D )
Comment #7
rfayWorks for me. I was hoping to see code that exercised it first, but go for it.
You may want to make a sample logging module that ships with this, if it's useful, that could listen on the hook.
Comment #8
mcurry commentedGood idea. I'll build a module that listens to all of the hook(s) we might end up implementing.
I am exercising the code in my (in-development) store module(s), thought that's not exactly heavy testing :D
The main reason I want to commit is that I don't want to accumulate too many local changes on my local filesystem... I'm new to Git but I'm in the habit of committing often when the changes stand alone.
Comment #9
mcurry commentedI can build the exerciser module and commit it with this patch. Time to bone up on Git...
Comment #10
mcurry commentedI've committed the new test module and the modified amazon_store.module file. Sadly, it took two commits, since somehow I missed the amazon_store.module on the first commit.
Comment #11
mcurry commentedFixing Version (since it's a patch to be ported)