I guess I was trying to keep my program "modular," reduce the number of global variables to a minimum, so I guess that's why didn't just use the array I made earlier later.

In retrospect, however, you're 100% right. I simply made @strmeta a global variable and didn't bother reprocessing the data. Then the problem went away and as an extra bonus, the page loads faster.

Thanks a lot, George!

--ghopper

Your'e welcome. I (and others doubtless) applaud your desire to be modular. How about this, then?: take your subroutine for printing output from an array. Not sure what you're calling this - say print_page. Now, instead of making @strmeta a global, make a local variable and pass a reference to it to the subroutine.

That is, call your subroutine like

my @strmeta = .....
[...]
print_page(\@strmeta);
[download]

Then in the subroutine make the first line

my $strmeta = shift;
[download]

And thereafter, where before you had @strmeta use @$strmeta, and where you had $strmeta[$foo] put $strmeta->[$foo] - which will "de-reference" (i.e. get the data out of) your reference $strmeta.

Then, if you set it up like that, you can call the same subroutine from two different points in your script - (a) when you've created @strmeta from your form input, and (b) when you've created it from retrieved data. Your subroutine won't care where the data comes from, so long as it comes in an array reference.

For your last trick, put print_page() in a module, and use it in all your other scripts!

Enjoy!

§ George Sherston

My theory is this: You have an array that holds the original file data; you then create some array which you modify via the splice. You then output the keys that you want to keep. You then read in the now modified file into the original array that you started with via some method that is not clearing the array before you read into it.

read from file to @orig
@orig = [ 1 2 3 4 A B C ]
@mod_copy = [ 1 2 3 4 A B C ]
splice @mod_copy
@mod_copy = [ 1 2 3 4 A C ]
print join of @mod_copy to file
file is now ( 1 2 3 4 A C )
read from file to @orig by indexing
@orig = [ 1 2 3 4 A C C ]
[download]

Something like this has to be right. I'll go check. Thanks a bunch, I'll report back!

You had to be right about this (your explanation was the only one I had and very elegant, to boot), but I couldn't spot where I was reading the changed file back into the array that you read the original into. I thought (could be wrong) I had made a local copy of the @strmeta ("structured metadata") variable for purposes of the deletion bits. I still think you had to be right, but I couldn't find the exact source of the error.

Instead I took George's advice and simply made @strmeta a global variable (er, well, I don't actually know if "global" is the right word--I didn't make a local copy), and didn't reload it after writing it to file, just used the altered @strdata array to print out the changed data. The problem went away!

Thanks very much to everyone!

--ghopper

You may need to turn buffering off on the filehandle you're using to write to the file. Also, if it weren't for other records immediately disappearing I'd suspect you don't truncate the file in which case the last record would stick around - but then it would have to happen for all records and wouldn't disappear on next refresh..

Makeshifts last the longest.

Items could be added via a form on the left and the items then were updated on the right.

In addition, the items on the right were displayed with a check box and that part was set up as a form as well so that multiple check boxes could be selected, and deleted all at once. When an item was deleted, the script called itself again so as to display the new data. That may be one option for you to consider in your program.

Hope that helps!

Some people fall from grace. I prefer a running start...

Yep, I'm doing something very similar. Basically, I've got a list of weblinks with checkboxes next to them. The function I'm working on simply allows the user to check off a bunch of boxes at a time, press "delete," and the selected links are deleted. The page calls itself.

I guess it would have been helpful to say that up front!

--ghopper

Thanks for the reply. I was afraid of that. The script is kind of long, and I'm not sure what is best thought relevant, but here we go. '$file' refers to the datafile I'm working with.

my $do;         # function
# Get delete_links input (which links should be deleted?)
if ( $input =~ m/Delete\+all\+checked\+links%21$/ ) {
    $do = 'delete';
    $input =~ s/(.*?)&delete_links=.*$/$1/ ;
    @del_links = split /&/, $input;
    @del_links = map {
        s/(\d+?)=checked/$1/ ;
        $_;
    } @del_links;
    @del_links = reverse @del_links;    # so that last ones are done f
+irst
}

[...]

my @metadata = &build_metadata_array;
my @strmeta = &parse_metadata(@metadata);
[download]

I am hoping you won't need to see the latter subroutines. The first simply reads in a datafile ($file), the second creates an array of references to the split data records. So, for example, @{$strmeta[0]} might consist of ('ap.1', 'ap.2', 'nyt.4', 'some random text about those ids').

if ($do eq 'delete') {
    foreach my $num ( @del_links ) {
        splice (@strmeta, $num, 1);
    }
}

[...]

# Rewrite metadata/$file
open (META, ">metadata/$file");
foreach my $rec ( @strmeta ) {
    my $summary = pop @{$rec};
    my $ids = join (/,/, @{$rec});
    print META "$ids\n$summary\n\n";
}
close META;
[download]

Is that enough?

Well, I don't know why it's failing (you didn't show us the code that reads the data for instance), but I do know this is going to fail if you are getting two requests in a short time. The first thing that happens when you open the file for write is that it's getting truncated. What if another instance is reading from the file? What if another instance is also writing? Your data will get corrupted. Also, you open the file, and you don't check the return value. What if the file cannot be opened? Same for the close, you might get an error here (disk full, for instance). You don't check.

Abigail