On 2005-04-28, Wojciech Pietron <[EMAIL PROTECTED]> wrote:
> Hi Tony,
>
> yes, it seams that this is a good solution. After that change I have no
> problems with CGI.pm in mod_perl and it works perfectly for me.
> Thank you, Tony.
>
> On the other hand I would like to know the opinion of Mark Stosberg, the
> noble author of DFV and the ability to change the code in official
> source. Mark, what do you think about it?
If it still passes the test suite but seems to help with this bug, I'm
interested. :)
However, I didn't like the idea of simply checking that the structure is
/not a hashref/ because that still leaves a lot of other wrong things it
could be besides a CGI.pm compatible object.
So I've rewritten the routine slightly differently. However, my personal
branch of DFV is in a great state of flux now, and I can't properly test
it without a new branch, which I'm too lazy to create right now.
Here's what I have in mind for a refactor. The key bit is that I skip
the test for whether or not I have an object, and test directly for the
presence of a 'param' method.
# Figure out whether the data is a hash reference of a param-capable object and
return it has a hash
sub _get_data {
my ($self,$data) = @_;
$self->{__INPUT_DATA} = $data;
require UNIVERSAL;
# This checks whether we have an object that supports param
if (UNIVERSAL::can($data,'param') ) {
my %return;
foreach my $k ($data->param()){
# we expect param to return an array if there are multiple values
my @v = $data->param($k);
$return{$k} = scalar(@v)>1 ? [EMAIL PROTECTED] : $v[0];
}
return %return;
}
# otherwise, it's already a hash reference
elsif (ref $data eq 'HASH') {
return %$data;
}
else {
die "Data::FormValidator->validate() or check() called with invalid
input data structure.";
}
}
>
> Best regards,
> Wojciech Pietron
>
> * Tony Fraser <[EMAIL PROTECTED]> [2005-04-26 18:37]:
>> On Tue, 2005-04-26 at 01:33, Wojciech Pietron wrote:
>> > Yes, I like it too. The reason I do not use CGI is its unresolved bug
>> > mentioned by Mark Stosberg on cascade-dataform list
>> > http://sourceforge.net/mailarchive/message.php?msg_id=7275077
>> > and CGI list:
>> > http://groups.google.com/groups?selm=83ca080.0402281631.368cd433%40posting.google.com
>>
>> Sorry about the off topic post but I'm not subscribed to
>> cascade-dataform and haven't actully used DFV yet myself.
>>
>> I was going over the archive messages and the following in the message:
>>
>> http://sourceforge.net/mailarchive/message.php?msg_id=7292541
>>
>> > At this point, I"m also suspecting it"s a CGI.pm issue. The extra
>> > "unknown" fields indicate that it"s actually producing different output
>> > with the same input. Although I recall making a test that just involved
>> > CGI.pm, and I couldn"t reproduce it. I have a question about this
>> > pending on the CGI newsgroup now as well.
>>
>> The extra "unknown" fields indicate to me that DFV is treating the CGI
>> object as a hashref for some reason. Could someone that is using DFV try
>> changing the line in _get_data() that reads:
>>
>> if (UNIVERSAL::isa($data,"UNIVERSAL") ) {
>>
>> to something like:
>> if (ref($data) ne 'HASH') ) {
>>
>> Now the problem is if this fixes the problem with DFV I'm at a loss as
>> to why it would.
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/[email protected]/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
