Inspired by an idea of JP Deni, which enabled me to add a "modify" button to search results that allows users to immediately jump to the modify form for a record without having to go through the modify subroutine in the footer, I thought of an alternate approach to long/short displays. The basic idea is: Search results return short displays be default. Next to each record there is a "display complete results"-button. Pressing the button gets the user to the full display for that very record.

Here's what I've done:

- in "html.pl": rename sub "html_record" to "html_record_complete"

- in "html.pl": add a new sub sub "html_record" which contains code for the short display embedded in form-tags: <form action="$db_script_url" METHOD="POST"><input type=hidden name="db" value="$db_setup">
<input type=hidden name="uid" value="$db_uid"><input type=hidden name="complete" value="$rec{$db_key}">Here comes whatever code you need to print the short version.
<input type="SUBMIT" name="complete_record" value="complete record"></form>

- in "db.pl" (which is, in my case, called "db.cgi"), go to the section that is commented as "Main Menu". To the list of "elsif"-clauses that's already there, add the following:
elsif ($in{'complete_record'}){ if ($per_view) { &html_record_complete; } else { &html_unauth; } }

Only problem is: I always get internal server errors when I call html_record_complete by pressing the button, and have no idea why. I ran both html.pl and db.cgi from the command-line, but the syntax is OK. Any ideas on why this doesn't work?








kellner

kellner:

What you are trying to do .. the short/long mod already does without it having to be modified. Except perhaps having a button rather than a link from the short display to the long.

Your long display should display the fields you setup within your html_record_long. I guess i'm not understanding why you are setting up another extra sub unless you are wanting yet another view of the long record?

Unoffical DBMan FAQ
http://webmagic.hypermart.net/dbman/

I know of course about the short/long mod. But my alternate approach is part of a larger plan (!) to redesign DBMan's functionality. I think it's more logical to have buttons (or whatever) that call the routines for modifying, deleting and display of complete records right next to individual entries in a list of search results than having to enter a whole new search routine every time you want to execute a task. What I want is a sequence "search > offer options to modify/delete/display long on search results" instead of "offer options delete - modify - display long > for each of these, enter a search routine, have the result displayed, select (if necessary) the record you want to modify or delete, and then do it." I haven't figured out yet how multiple deletes or multiple long displays would work on my approach, but I don't think it would be impossible.
Please understand that I'm not using the short/long mod. I rename html_record to html_record_complete: This is the long display. I then add a new sub called html_record for the short display. You could of course also modify html_record to be the short display, and then add another sub for the long display. But you have to add at least one more sub.

kellner

From what you wrote in your other thread, it seems that you wanted me to respond. What did you want? If what you have works, then there's nothing for me to say.


JPD
http://www.jpdeni.com/dbman/

No, the problem is that what I have *doesn't* work. What I did is this:

- in "html.pl": rename sub "html_record" to "html_record_complete"
- in "html.pl": add a new sub sub "html_record" which contains code for the short display
embedded in form-tags: <form action="$db_script_url" METHOD="POST"><input
type=hidden name="db" value="$db_setup">
<input type=hidden name="uid" value="$db_uid"><input type=hidden name="complete"
value="$rec{$db_key}">Here comes whatever code you need to print the short version.
<input type="SUBMIT" name="complete_record" value="complete record"></form>

- in "db.cgi", go to the section that is commented as "Main Menu". To the list of "elsif"-clauses that's already there, add the following:
elsif ($in{'complete_record'}){ if ($per_view) { &html_record_complete; } else {
&html_unauth; } }

Only problem is: I always get internal server errors when I call html_record_complete by
pressing the button, and have no idea why. I ran both html.pl and db.cgi from the
command-line, but the syntax is OK. Any ideas on why this doesn't work?

kellner

To figure out what's going on, I would delete everything in html_record_complete (saving it some place safe ), and just have

print "complete record";

in the subroutine. That will tell you if the problem is in html_record_complete. If you get

complete record

to show up, you'll know it's in html_record_complete.

From what you've posted, that's probably where the problem is.

JPD
http://www.jpdeni.com/dbman/

The problem with html_record_complete was that I had forgotten to print out the html headers, as I realized when, following your advice, pressing the "complete" button got me that dreaded "you have started to download a cgi-file".

What I don't quite understand now is that neither the modify routine, which I implemented in the exact same fashion in a different dbman installtion, nor the complete routine seem to get the values from html_record passed on.

With the modify routine, pressing the button "modify" gets the user to sub html_modify_form_record, which starts with "my (%rec) = &get_record($in{'modify'});". This works the another dbman installation, but NOT for this one. The only relevant (?) difference between the two html.pl-files is that html_record does not print the entire record, but only a few fields (as it is the "short" display) in the problematic case, whereas it does print all fields in the case where the whole thing works. But somehow it seems odd that PRINTING should make a difference. Shouldn't all the values be in the %rec-hash in html_record and be passed on to subs that are called from it?


kellner

Not if you use my (%rec) = &get_record($in{'modify'});

"my" causes whatever the variable is to be local to the current subroutine.

JPD
http://www.jpdeni.com/dbman/

OK. Another try to understand the logic behind this. If I use my (%rec) = &get_record($in{'modify'});, then the sub get_record "given an ID as input, returns a hash of the requested record or undefined if not found." (that's its comment as given in db.cgi). Now, from the debug info I know that $in{'modify'} (or $in{'complete'}), which has the record's ID as its value, is indeed passed on to the subs html_modify_form_record or html_record_complete. So calling "get_record($in{'modify'})" should make the database entry for this particular record id available to the subs, no? But no record is displayed, even though all the other formatting code contained within the subs is displayed correctly. I just don't get it. Sigh.

kellner

If you use my (%rec) = &get_record($in{'modify'});, the %rec hash will be available to the subroutine where the line is and no other.

"my" means that the variable is only available in the current subroutine.

If you want the hash to be available to another subroutine, you have two choices, you can either pass the hash to the other subroutine or you can get rid of the "my."

To pass the hash to the other subroutine, use

&subroutine_name(%rec);

and, at the beginning of the other subroutine use

my (%rec) = @_;

Or you can just use

%rec = &get_record($in{'modify'});

If you do that, it will be available to all subroutines.

JPD
http://www.jpdeni.com/dbman/

OK. Assume I have a form in html_record pass on "complete_record" to db.cgi, where I have an elsif_clause in sub main that, if this value exists, calls html_record_complete in html.pl.
The form also passes on the dbkey via a hidden input field called "dbkey", and of course the values of the record on display.
I then have two possibilities to get precisely these values to html_record_complete (apart from declaring %rec globally):
- in db.cgi, use "&html_record_complete(%rec);" and then start html_record_complete with "my(%rec) = @_;" (after having printed the header)
- in db.cgi, use "&html_record_complete;" and then start html_record_complete with "my(%rec) = &get_record({$in{'dbkey')});" (after having printed the header)

I tried both, none of them works. At a loss,

kellner

I still have yet to get a clear picture of what you're trying to accomplish.

You can't use

&html_record_complete(%rec);

unless you have first pulled up the record.

If my(%rec) = &get_record({$in{'dbkey'}); doesn't work, then there are two possiblities. Either there is nothing in the variable $in{'dbkey'} or there is no matching record.

I think it's the former.

From several posts up, it appears that you have a field

<input type=hidden name="complete" value="$rec{$db_key}">

that is sent to the script. You might try

my(%rec) = &get_record({$in{'complete'});

since that is the name of the field that was sent to the script.

JPD
http://www.jpdeni.com/dbman/

By "pulled up", I guess you mean I must have searched for it. Which I have, since the form which calls html_record_complete is embedded in html_record - I'm calling the sub from the search results.
There is something in the variable, because when I call html_complete_record, the debug info below the resulting page (on which unfortunately no records are printed) informs me that the value of dbkey is the id of the record in question. So I assume that the value is passed on correctly, but for some reason not printed. It's that reason I'm after. Also, if the value didn't exist, "get_record" should return an error message.
In the meantime I've renamed "complete" to "dbkey", so that's in fact what I am doing. Sorry for not having made this clear.

kellner

At this point, the only thing I can do is look at your files.

Please copy them to a web-accissible directory (one where you would place .html files) and rename them with a .txt extension. For example db_cgi.txt. Then let me know where I can find them and I'll take a look.

JPD
http://www.jpdeni.com/dbman/

Thanks a lot. Here are the URLs for the two files:

http://mailbox.univie.ac.at/Birgit.Kellner/lofohtml.txt
http://mailbox.univie.ac.at/Birgit.Kellner/db.txt

kellner

Some questions --

Do you have $auth_modify_own=1; in your .cfg file?

Does this happen the same whether you are logged in as admin or as a "regular" user?

Do you get the page, but just not the values?

JPD
http://www.jpdeni.com/dbman/

No, I have $auth_modify_own=0; and $auth_user_field=-1;
The "modify" button only appears when the user has admin permissions, the "complete record" button appears when the user has viewing permissions. In case of the "complete record" button, the same happens no matter how I log in.
Exactly.

kellner

The first thing I would try is, in sub html_complete, before

my (%rec) = &get_record($in{'dbkey'});

add

$in{'dbkey'} =~ s/<.?B>//g;

Or you could just set $db_bold = 0; in your .cfg file. If it works after this, you'll know the problem was because of bolding tags.

Actually, I can't think of anything else. Give this a try and see what happens.

JPD
http://www.jpdeni.com/dbman/

This actually did it for html_record_complete - complete display works like a charm, thanks!
Modifying still doesn't work, though - no records displayed.
The value of $db_bold does not affect any of this, apparently.

Thanks again,

kellner

Well, we're halfway there.

Try this -- in sub html_record_form, after

my (%rec) = @_;

add

$rec{$db_key} =~ s/<.?B>//g;


JPD
http://www.jpdeni.com/dbman/

no, that didn't remove the problem.


kellner

Well, then we'll have to dig some more.

You're getting a blank form when you try to modify? Or a blank page?

JPD
http://www.jpdeni.com/dbman/

Somewhat closer to heaven: I set $db_bold=0 (which removed the bold tags from the ID-value that's passed on to the subs, thank you), and then added names to the forms on sub html_record and html_modify_form_record. Now I get the values in the form allright, though I have two more display problems to sort out. One's clear: I have html-links in the database entries, where I apparently have to replace double with single quotes, because otherwise they won't get displayed completely: In the form, the text will only be displayed up to the (double) quotation-mark after <a href=, because it's given as a value of a VALUE: VALUE ="<a href=">.
Fine. Live and learn. Curiously enough, the values of the textarea fields are not displayed, even though they exist, as can be seen from the sourcecode. I haven't figured out that one yet. Live a little longer, learn (hopefully) more.

kellner

That is odd. I don't understand that at all.

Glad you got at least some of the rest of it figured out.

JPD
http://www.jpdeni.com/dbman/

OK, I discovered the final error, which was a really stupid mistake in my coding of the textarea fields in html_record_form.
I also added another feature based on the same routine, but will describe that in a new thread called "instant modifying/deleting of search results".
Thanks again JPDeni for the lots of help,


kellner