oh right that should be E_USER_ERROR or whatever you see as necessary, actually I'm in the middle of error handling for the api code so I can populate faultCode's with meaningful errors, E_WARNING is defined for me but won't be for you because trigger error only works on E_USER_* constants normally ...
at this moment, it checks the parameter passed against the email, address and hostname.
I think logically type should be rewritten. I think it would be better if these methods were overloaded, the signatures being something like
method( api, match )
method( api, email, address, hostname )
That way you can execute match( api, method ) if you only have one piece of information, such as an email or ip, and return any records of that type containing match in email, address or ip.
OR
You can execute method( api, email, address, hostname ) if you have all the information and return matches that contain any of it ...
Am I right ??
I want to leave search the way it is more for windows or standalone web applications rather than integration, but type could be useful for such logic as
PHP:
<?php
if( ( $created = $type->created( params ) ) )
{
if( ( $deleted = $type->deleted( params ) ) )
{
if( count( $deleted ) != count( $created ) )
{
printf( "You have been hosted for free at %d other locations, please use one of those accounts", count( $created ) - count( $deleted ) );
}
}
}
?>
<?php
if( ( $criminal = $type->criminal( params ) ) )
{
printf( "You have had %d criminal flags raised, this is unacceptable, we will not host you", count( $criminal ) );
}
?>
<?php
if( ( $suspended = $type->suspended( params ) ) )
{
if( count( $suspended ) > 5 )
{
printf( "You have been suspended on %d other services, this is over our threshold", count( $suspended ) );
}
}
?>
Type should provide logic that needn't analyze the data returned too much, where search should really return as much as possible for manual analysis.
So rewrite type with overloaded methods ??
