> using Net::LDAP I had a problem when I wanted to hand of a stringified version
> of a single result record (object of type Net::LDAP::Entry): it seems like
> it's only possible to dump a record directly to a file handle
> (Net::LDAP::Entry->dump)?!

> So in case anyone else finds this useful (and in case I didn't miss something)
> I've appended a small patch to Net/LDAP/Entry.pm (and Net/LDAP/Entry.pod)
> which provides a dumpstr() method to return a stringified record.

>     This method is intended for debugging purposes and does not treat
>  binary attributes specially

>     See Net::LDAP::LDIF on how to generate LDIF output

> so this really should not be used for passing around entries

>   open(my $fh,">",\my $buffer);

>   then pass $fh as the file handle

> something like (untested)

> sub ldif {
>   my $self = shift;
>   require Net::LDAP::LDIF;
>   open(my $fh, ">", \my $buffer);
>   my $changes = $self->changes ? 1 : 0;
>   my $ldif = Net::LDAP::LDIF->new($fh,"w", changes => $changes);
>   $ldif->write_entry($self);
>   return $buffer;
> }

>> Also, anything that can dump to a filehandle can dump to a string.
>>  open(my $fh,">",\my $buffer);
>>  then pass $fh as the file handle

> Only in perl >= 5.8.  Perl 5.6 and earlier won't support this syntax, so  I would advise against using this to implement and ldif() method unless you are OK with breaking compatibility with older perls...

Am Mittwoch 10 Februar 2010 15:17:25 schrieb Graham Barr:

> I am in two minds as whether to accept this as a change. As the docs state

>     This method is intended for debugging purposes and does not treat
>  binary attributes specially

>     See Net::LDAP::LDIF on how to generate LDIF output

> so this really should not be used for passing around entries

I didn't intend to pass around the stringified entry - but you're right:
people would quite probably try to use it that way.
As for not treating binary attributes specially: If dump() could live without,
I concluded that dumpstr() could do so, either....
 
> Also, anything that can dump to a filehandle can dump to a string.

>   open(my $fh,">",\my $buffer);

>   then pass $fh as the file handle

I consider that a not so well known solution. At least I had to look it up
yesterday - well, given my programming skills that's probably not a sensible
criterion.... ;-)

Regarding Christophers reference to it lacking backward compatibility: One
might use IO::String instead. But that would add another module dependency.

> Having said that maybe Net::LDAP::Entry could use an ->ldif method

> something like (untested)

> sub ldif {
>   my $self = shift;
>   require Net::LDAP::LDIF;
>   open(my $fh, ">", \my $buffer);
>   my $changes = $self->changes ? 1 : 0;
>   my $ldif = Net::LDAP::LDIF->new($fh,"w", changes => $changes);
>   $ldif->write_entry($self);
>   return $buffer;
> }

Well, that works. Output does not look as nicely formatted and readable as the
original dump() output, but that's certainly an acceptable trade-off for being
more complete and "correct". Which makes me think that it could be used inside
dump(), too.

Heiko

>   open(my $fh,">",\my $buffer);

>   then pass $fh as the file handle

>>> Also, anything that can dump to a filehandle can dump to a string.
>>>  open(my $fh,">",\my $buffer);
>>>  then pass $fh as the file handle
>> Only in perl >= 5.8.  Perl 5.6 and earlier won't support this syntax, so  I would advise against using this to implement and ldif() method unless you are OK with breaking compatibility with older perls...

> 5.8.0 was released nearly 8 years ago. Anyone who is still using a version of perl that old will not mind using an old version of Net::LDAP IMO.

>>>> Also, anything that can dump to a filehandle can dump to a string.
>>>>  open(my $fh,">",\my $buffer);
>>>>  then pass $fh as the file handle
>>> Only in perl >= 5.8.  Perl 5.6 and earlier won't support this syntax,
>>> so  I would advise against using this to implement and ldif() method
>>> unless you are OK with breaking compatibility with older perls...

>> 5.8.0 was released nearly 8 years ago. Anyone who is still using a
>> version of perl that old will not mind using an old version of Net::LDAP
>> IMO.

>>> Graham Barr wrote:
>>>> On Feb 10, 2010, at 9:35 AM, Christopher Bongaarts wrote:
>>>>> Graham Barr wrote:

>>>>>> Also, anything that can dump to a filehandle can dump to a string.
>>>>>>  open(my $fh,">",\my $buffer);
>>>>>>  then pass $fh as the file handle
>>>>> Only in perl >= 5.8.  Perl 5.6 and earlier won't support this syntax,
>>>>> so  I would advise against using this to implement and ldif() method
>>>>> unless you are OK with breaking compatibility with older perls...

>>>> 5.8.0 was released nearly 8 years ago. Anyone who is still using a
>>>> version of perl that old will not mind using an old version of
>>>> Net::LDAP IMO.

>> I disagree with this statement. ;)  RHEL4, for example, ships with perl
>> 5.8.5, and remains one of the most widely deployed Linux distributions
>> in the corporate environment.

> I didn't hear the OP referring to 5.8.x as "old" but as anything prior to
> 5.8.0 as old. The 5.6.x line is officially unsupported[0] so I think
> Christopher is correct.

>> Graham Barr wrote:
>>> On Feb 10, 2010, at 9:35 AM, Christopher Bongaarts wrote:
>>>> Graham Barr wrote:

>>>>> Also, anything that can dump to a filehandle can dump to a string.
>>>>>  open(my $fh,">",\my $buffer);
>>>>>  then pass $fh as the file handle
>>>> Only in perl >= 5.8.  Perl 5.6 and earlier won't support this syntax,
>>>> so  I would advise against using this to implement and ldif() method
>>>> unless you are OK with breaking compatibility with older perls...

>>> 5.8.0 was released nearly 8 years ago. Anyone who is still using a
>>> version of perl that old will not mind using an old version of Net::LDAP
>>> IMO.

> I disagree with this statement. ;)  RHEL4, for example, ships with perl
> 5.8.5, and remains one of the most widely deployed Linux distributions
> in the corporate environment.