Caller ID Superfecta

Began some preliminary work for this. I have been in email communication with lukicweb for some help in translating some of the page output and for help with number format etc. I have started out using http://www.belestrane.988info.rs/site/ (white pages listings) but could not get anything to work using MS internet explorer. Switching to firefox got expected behavior. Here is a summary of our email communication:

Translations:
"Mrezna grupa" this is like area code
phone format is like 011 xxx-xxxx
Second field is city but that can stay as "Sva mesta" which means all places
'Telefon" phone number
Ime name
"Prezime" last name
"Ulica" -street
"broj" -number
two butns "Trazi" is search and "Ponisti" is cancel
"Za zadati kriterijum nisu prona?eni podaci!" - For requested criteria there is no data

The page that does the actual work is this URL http://www.telekom.rs/WhitePages/SearchPage.asp?Mg=019, this example passes area code 019 but I havn't figured out yet how to pass the phone number. I may need some help with this one.

user jkiel from PIAF forums created the two files attached which is the lions share of the work done. Left outstanding at this point is number format checking.

1. Combined functions into the souce code php file in order to facilitate future updates to the source and to bring it in line with formats of other sources
2. renamed variables as appropriate. Note to jkiel you can't alter the value of $thenumber, if the lookup fails, it will cascade to the next lookup source with the value altered.
3. Removed most of the number checking because it was blocking some acceptable numbers. If lukicweb will help with all the possibilities, more sophisticated number format checking can be added.
4. renamed source file to bring it in line with others

This source is ready for testing

After having written #2 in the post immediately above, I have gone back and looked thru several sources and am wondering now if that is correct. Please someone confirm.

lgaetz wrote:

1. Combined functions into the souce code php file in order to facilitate future updates to the source and to bring it in line with formats of other sources

It would be best if these functions could be made globally available to other sources. They are not unique to Serbian numbers.

I see one thing to change, and is left from when I was debugging the code. Line 157 should probably change from:
curl_setopt($ch, CURLOPT_FAILONERROR, 1);
to:
curl_setopt($ch, CURLOPT_FAILONERROR, 0);
As it is, an error will be raised if the page fails to load properly.

1. renamed variables as appropriate. Note to jkiel you can't alter the value of $thenumber, if the lookup fails, it will cascade to the next lookup source with the value altered.

I wondered about this. The White Pages source that I used as a template did modify $thenumber -- though as you point out it probably isn't a wise move.

jkiel wrote:

I see one thing to change, and is left from when I was debugging the code. Line 157 should probably change

Change committed to repository see r276

jkiel wrote:

The White Pages source that I used as a template did modify $thenumber -- though as you point out it probably isn't a wise move.

I didn't think that altering $thenumber was permitted, but I see many of the lookup sources do. Can someone confirm one way or the other please. In this document http://projects.colsolgrp.net/documents/8 it states:

Be careful not to modify a variables already used by bin/callerid.php as their value need to be used by other sources

lgaetz wrote:

I didn't think that altering $thenumber was permitted, but I see many of the lookup sources do. Can someone confirm one way or the other please. In this document http://projects.colsolgrp.net/documents/8 it states:

Be careful not to modify a variables already used by bin/callerid.php as their value need to be used by other sources

Looking at callerid.php, in the foreach source loop, line 233 has "$thenumber = $theoriginalnumber;" before the eval that includes the source. So in this case, it appears $thenumber is reset for each source.

The problem is that each source will still share variables. source-White_Pages.php, for example, uses $error_number as a flag to skip processing if the $thenumber does not appear to fit the requirements of the source. Since I used source-White_Pages.php as a template, source-Telekom_rs_SR.php uses $error_number as well. Unfortunately, source-White_Pages.php does not reset $error_number to a default of false (source-Telekom_rs_SR.php does) so if source-Telekom_rs_SR.php sets $error_number = true before source-White_Pages.php runs, source-White_Pages.php will not perform a lookup, even if it should.

source-Telekom_rs_SR.php could be modified to set $error_number = false; before it exits, but the better solution is to fix source-White_Pages.php, and any other script that makes assumptions on the state of a variable on script entry. In short, I propose that each source should assign a default value to variables it will use.

jkiel wrote:

In short, I propose that each source should assign a default value to variables it will use.

Thinking this through further -- perhaps each source should be wrapped in its own class or function. This would certainly take some time to implement, and could/would break existing sources -- but would keep them more isolated from each other, limiting the problems a buggy source could cause.

If I understand this correctly, you are suggesting that this data source be composed of two separate file. If so - that will break The Live Update function. Please assess this - we wont release any data source that wont work with live update.

When I first submitted the code to lgaetz, before I had access here, I was unsure where to put functions (only to later discover that there is no "neat" place to submit new functions). lgaetz combined them into one source file, source-Telekom_rs_SR.ph, which unfortunately doesn't work. See r287 for my resolution to the issue.

It sounds as if this case is a dunsel, and should be closed. Yes?

Yes, I think think this ticket could be closed.

Ticket can be QS and closed once related #384 has passed QS and is closed..

QS: Pass. Connected issue #384 has already been closed.

The required architectural changes have been made to support this data source.

These changes have been accepted into build for 2.2.4

This data source should not be added to live update untill the module v 2.2.4 is released - since it is dependant upon changes in #384.