Re: Net::LDAP::FilterMatch

[[EMAIL PROTECTED]]

Peter, I'm a bit too lazy for cmdline tools, however using /repos/ instead of  /wsvn/ also works for me, might be a hint in the project FAQ, creating a diff is suddenly a breeze and so is keeping up with your versions ;-) There's a bug in your version 0.14 which causes substring match with schema to fail , it is fixed by the attached patch. The regex match works,  however its not very common for clients to specify regexes (we might specify a new match for that ;-), I was actually looking for something which matches things like schmidt schmit schmitt etc... therefore I added a list of modules which will be tried (String::Approx, Text::Metaphone, Text::Soundex in that order) , if you have none it will fall back on the original regexp. Cheers, Hans Peter Marschall schreef: Hi Hans, On Sunday, 15. January 2006 21:48, [EMAIL PROTECTED] wrote: I've created a 0.14 (see attached patch ;-)) which contains more matching rules and some other small fixes. However to post patches, it would be very convenient to have *readonly* svn access. I tried using tortoise SVN but I get a forbidden. Am I doing something wrong ? You should be able to create a local working copy of the repository using the command "svn co http://svn.mutatus.co.uk/repos/perl-ldap/trunk/". Using "svn diff" inside the perl-ldap directory you can generate the patch of your changes, and using "svn update" you can update your working copy to the latest changes from others. (sorry, I'm a command line junkie ;-) I removed the "use Net::LDAP::Filter" & "use Net::LDAP::Schema" as it does not seem to harm code execution. I'd like to keep then in to keep Perl happy even if the user did not specify these two use clauses in his script. Having them in does not hurt either ;-) The module seems to be strict, however the &$match is not allowed when strict is active (thats why my initial version used the eval ) Rest committed with a few changes (to make it a bit more readable for me ;-))) Since the patch did not apply cleanly I had to apply a few hunks of it manually. Please check if the result is what you wanted. Regarding the approx, we could use Text::Soundex or String::Approx and conditionally load that if present on the system, "just" a regexp would be perfect, but I haven't come across one yet ;-) _cis_approxMatch() should do regexes already. Have a try with the attached test file. It might not be perfect (owing to interactions of the regex syntax with the LDAP filter syntax) but better than none. CU Peter

Index: FilterMatch.pm
===================================================================
--- FilterMatch.pm      (revision 483)
+++ FilterMatch.pm      (working copy)
@@ -15,7 +15,7 @@
 
 package Net::LDAP::Filter;
 
-$VERSION   = '0.14';
+$VERSION   = '0.15';
 
 sub _filterMatch($@);
 
@@ -80,7 +80,7 @@
        greaterOrEqual  equality
        lessOrEqual     ordering
        approxMatch     approx
-       substring       substr
+       substrings      substr
 );
 
 sub _filterMatch($@)
@@ -256,10 +256,25 @@
 my $assertion=shift;
 my $op=shift;
 
-  #print "approx assertion '". $assertion ."'\n";  
+  if (eval ("require String::Approx")){
+    #print "using String::Approx\n";
+    return String::Approx::amatch($assertion, @_) ? 1 : 0;
 
-  return grep(/^$assertion$/i, @_) ? 1 : 0;
-  # better: by use String::Approx or similar
+  }
+  elsif (eval ("require Text::Metaphone")){
+    #print "using Text::Metaphone\n";
+    my $metamatch = Text::Metaphone::Metaphone($assertion);
+    return grep((Text::Metaphone::Metaphone($_) eq $metamatch), @_) ? 1 : 0;
+  }
+  elsif (eval ("require Text::Soundex")){
+    #print "using Text::Soundex\n";
+    my $smatch = Text::Soundex::soundex($assertion);
+    return grep((Text::Soundex::soundex($_) eq $smatch), @_) ? 1 : 0;
+  }
+  else{
+     #we really have nothing, use plain regexp
+     return grep(/^$assertion$/i, @_) ? 1 : 0;
+  }
 }
 
 1;