Hi Pugdog,
With some sites and their needs, and the current state of Linksql it's sometimes impossible to maintain upwards compatibility. This is one of those cases. Even if Use Links::Mailer, I still have to call Links::Init in my calling cgi program. That doesn't solve the problem. The problem is that it's impossible to do the following twice:
read (STDIN, my $data, $content_length, 0);
GT does it once in GT::CGI::load_data:
read (STDIN, my $data, $content_length, 0);
$data =~ s/\r?\n/&/g;
$self->parse_str($data);
Now that GT's done it, if I do this or anything similar $data is blank:
read (STDIN, my $data, $content_length, 0);
And visa versa is true as well. If I do the read before callings Links::Init. I can read, but then GT::CGI::load_data cannot. Interesting huh.
Anyway, I need the $data string before it's been parsed, because the GT parsing process puts everything into a hash. The original order then gets lost and there is now way to get it back.
How does Links::Mailer help overcome that? I'm just doing this when it comes time to send the email:
# Mail the validation letter.
require GT::Mail;
GT::Mail->send ( {
smtp => $CFG->{db_smtp_server},
sendmail => $CFG->{db_mail_path},
from => $Config->{email},
subject => $Config->{subject},
to => $Config->{recipient},
msg => $input->{mailloop_results}
} ) or die $GT::Mail::error;
I have 7 email forms all asking different questions so there's not really a way to standardize the incoming fields. My only hope when using post is to read in the order during the load_data process, so I can spit them back out in that same order. That just means I've got to make some teeny little changes in GT::CGI each time I upgrade. It's a pain I know, but I always hope that GT reads these and makes notes on the subtleties that are still missing in LinksSQL.
Most of the sites I've done have required the same customization of GT's code.
I always have to modify Links.pm::clean_output and user_page - for several reasons:
1. to clean javascript ouput cause it doesn't properly parse onclick=newwindow('<%URL%>').
2. to stop multiple
dynamic_preserve variables from returning like d=hash(0x0860) in my urls;
3. to allow LinksSQL to preserve the variables even if d is not set (Alex thought this a good idea, I don't know if he's planning on implementing it.) The original discussion is here:
http://www.gossamer-threads.com/...earch_string;#186989 I always have to modify browser.pm so that links show up in Editor listed in the same order as they do on the site (like isValidated DESC, $CFG->{
build_sort_order_category}.
I always have to change GT::Display::HTML so that radio buttons are on the left side of the value as are the checkboxes and to get checkboxes and radio buttons to list in multiple columns.
I always have to install a category plugin so that I can allow any given Category to specify it's own link order and so that I can know what category a link belongs to when I'm printing the link, as that info is not passed when building the link code. (it doesn't make sense to look it up again when it's already available.)
I keep customized versions of changed files on hand for the upgrades, so that I can just upload over the new code with my modified code. It's a pain I know, but often I'm left with no other real choice. What the client demands is what ultimately rules the decision making process.
peace.
klangan
. I can then reference it as $IN->{inc_order} It'd be cool if GT could do something similar in a future release.