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
