Gossamer Forum
Home : Products : Gossamer Links : Discussions :

BUG: Logic bug in modify.cgi

Quote Reply
BUG: Logic bug in modify.cgi
ALex,

Here's another one.

In modify.cgi

Code:
foreach my $key (keys %cols) {
if (exists $CFG->{add_system_fields}->{$key}) {
$new->{$key} = $link->{$key};
}
else {
my $val = $IN->param($key);
$new->{$key} = defined $val ? $val : $link->{$key};
}
}
What happens, is that other fields that are passed into the form are _NOT_ saved in the Changes table database record.

This prevents a plug-in from adding fields for checking.

_ALL_ data should be saved in the Changes table, since like Preview this may contain significant numbers of extra fields.

Then, when _actually_ saving the data to the Links table, (or other tables) the library routine uses the

foreach my $key (keys %cols)

for "safety" and to prevent database errors.

I hope I'm clear, but I just spent 2 hours trying to figure out why my upload file was not being passed to the plug-in either in a pre or post hook! And I think this is why. I'm going to hack around it for now, but a better way (official) needs to be figured out!

Even if I pick the data out in from the "$IN->param()" hash, those changes are ignored pretty much, and writing to $IN is not the best thing to do.

I guess the plug-in could try to read the changed table entry in the Changes table, rather than just pass the new values back to modify.cgi, but it seems logically that modify.cgi should be more "lenient" saving change data, and the library routines need to be "strict" in generating the SQL statement.

Either way, I had a problem with the modify routines in the beta, and now that I'm trying to release a stable version, I'm having to deal with them :) Some official way of dealing with the flow of data through modify.cgi should be set down, otherwise, plug-ins will be overriding each other, cancelling each other out, and doing other funny things, when really it's a core "feature" of modify.cgi's internal subroutine that is literally dropping the ball :)







PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://pugdog.com/FAQ


Quote Reply
Re: BUG: Logic bug in modify.cgi In reply to
Hi,

Are you saying that instead of saving $link modify should be saving $IN? I could see how this would be useful for people who want to pass non column information through the modification process. I'll look at changing this.

Cheers,

Alex

--
Gossamer Threads Inc.
Quote Reply
Re: BUG: Logic bug in modify.cgi In reply to
Alex,

That is one part of what I'm saying.

What I'm really saying is that all the routines need to behave the same way, and in a predictable fashion.

The routines should not expect (or use) non-passed input, and they need to pass out the input they recieve. They shouldn't pass out input that is not expected (or tags will get crunched) and they shouldn't screen out tags that are expected to be passed out.

I'm not sure how this applies to all the routines, but one part of the developer manual (and hooks descriptions) need to be not only the data type that is passed in and out, but also what is done to that datatype.

For example, on the modify, what should be passed out is the $IN->(param) hash, with the $new hash added _on_ it (overwriting old values). Then, $IN still contains the original passed in values, and $input (or $link) contains _ALL_ values as acted upon by the modify.cgi routines.

What happens, is that modify.cgi screens out all the passed information except what is in the %cols hash (I assume read from the .def files).

An extension of this, is that the "changes" database really should store all the passed in data, to save "state" from the form changes, in case another hook has to act on the data BEFORE it's validated.

Remember, in the Preview table there were extra fields that were used to define how the data would be updated or validated, which were not carried over to the Links table. _pre- hook information should be stored in the database record, so it's available to _post- hooks and to the Validate routines on the next pass.

Complicated... and I'm in the middle of bedlam at the moment so I'm probably not really clear.

PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://pugdog.com/FAQ


Quote Reply
Re: BUG: Logic bug in modify.cgi In reply to
Hi,

Modify now saves $IN with $new keys on top of it. Also, it stores the latest modification only.

Cheers,

Alex

--
Gossamer Threads Inc.
Quote Reply
Re: BUG: Logic bug in modify.cgi In reply to
Great :)

Don't know if you are married with children, but 2 rug rats is about equal to a daily server crash :)

PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://pugdog.com/FAQ