if i wanted to reset all default values to default when i modify a record, what would be the correct code?

is see:

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

....

&html_record_form (%rec);

in html_modify_form_record.

i see

&html_record_form (&get_defaults);

in the add record form. where would i put (&get_defaults) in the modify routine?

I'm not sure I understand why you would want to basically delete the records when you go to modify them, it would seem to defeat the purpose of being able to make changes.

When you add a record it would take the defaults from your .cfg file, but when you modify a record it reads the information from the .db file.

Unoffical DBMan FAQ

http://creativecomputingweb.com/dbman/index.shtml/

i would not want to delete the record, just restore certain default fields. i can think of a few applications for this:

to establish a default value for a field for which no value was previously required. perhaps a yes/no field that could be left blank, but now want the default to be yes. whenever a record is modified the default could then be displayed in a special color so the user would see the default and make a conscious decision.

When you modify a record it should display select, checkboxes, and radio buttons that have been setup.

It may just be me, but I really think that adding the default values back in during a modify could really confuse people and perhaps they wouldn't check to see that they really wanted those values added.

Maybe someone else will come along and give you some ideas or suggestions.

Unoffical DBMan FAQ

http://creativecomputingweb.com/dbman/index.shtml/

another application would be to call a subroutine that performed calculations or string manipulations such as combining entries of firstname and lastname into name. i would like to do this in a subroutine so that all such things are done in a convenient place for me to edit as needed for different databases. i hope this makes sense. and as i think it through, i think this routine would need to be called from somewhere else, perhaps modify_success. hope this makes more sense. i have a basic perl book but it doesn't even mention things like &get_default so it took awhile for me to figure out that somehow the & is calling a subroutine. but when you have &do_something (&do_somethingelse) i don't know which routine is called first and how the second routine knows what it's getting!

This may be the blind leading the blind, but I think the inner sub is run first, just like any math equation.

The information that the sub uses is passed via @_

such as;

my (%rec) = @_;

It took me some time to figure that out too.

One example for nested subroutines is in sub html_view_success:

&html_record(&array_to_hash(@hits));

The array @hits is passed to the subroutine array_to_hash, which returns %rec to the subroutine &html_record, which begins with "my %rec = @_;" and in this way takes over the torch.

If you want values forced where they were not required before, you can just edit your .cfg-file and change the "0" into a "1" at the appropriate position for the field in question (I forgot how it's called, I think "non-empty" or something).

If you want default values in certain fields for ALL entries, then you can just add them in your .cfg-file, for the field where you want to have them. But as LoisC says, it seems a very bad idea to call these defaults on modifying.

Let's say, for instance, you have a field for links in your db. Because you didn't specify a default, users entered strings like "www.server.com/dir/stuff.html" or "http://www.stuff.org/dir/link.html". Now it occurs to you that it would be a good idea (1) if the field already automatically contained "http://" in the beginning. You can enter this as "db_default" in the database definition, and when new records are added, this string will already be printed in the input field and also added to the database. Fine.

But what about entries that already exist? If you add a call to "&get_defaults" to html_modify_form_record, then the string "http://" will REPLACE whatever was in that field before. Bad idea. Better: Either go over the database and make necessary changes yourself, or add a check in html_record:

unless ($rec{field} =~ /^http:\/\//) { $rec{field} = "http://" . $rec{field}";}

Just rambling on :-)
kellner

let's see if honesty is the best policy -- i am trying to modify db.cgi and database.cfg to contain all the code that needs to be modified for an individual database. i love autogenerate and find that it looks great when used in conjunction with short-long and a stylesheet. ok, i know that that short-long will need to be customized for each database. but i'm using the user-friendly mod, i've stripped out all the font stuff and am referencing a stylesheet, i've set up format.pl (with separate name where appropriate) and requiring it from cfg (so i don't have to modify html.pl !)

now what i really want to do is not change stuff to defaults. what i want to do is perform calculations, such as setting name = firstname + lastname when a record is modified. the change needs to be made after the user modifies the record but before the record is rewritten to database. i don't want to modify html.pl to do the calculations. instead, i want to have a section of cfg that defines the calculations that need to be made when a record is modified.

i hope this makes sense. it just seems to me that the software would be so much easier to use if all the changes could be made in one place.

now, will my honesty be rewarded with an answer!? :) thanks!

My approach in a similar situation was actually the reverse: (a) modify db.cgi as little as possible, (b) make all necessary modifications in the .cfg-files *and* individualized html-files which I created in addition to html.pl.

These individualized html-files include the routines html_view_success, html_record, and html_record_form. I found that in the course of time, I did have quite a few things to modify especially in html_record_form, and autogenerate in the long run was just no longer an option. Mind you, even with those databases where I use autogenerate, I had to include quite a few if-blocks into the build_html_record sections as well. In multi-database setups, there's always a border where you decide to make certain subroutines database-individual, but where you set the border is a personal matter. Is it more work maintaining numerous if-blocks in general subroutines, or is it more work maintaining the common code in individual subroutines? A question of degree.

In case of the name field example, you might want to consider: do you really need the combined name in the database or wouldn't it be sufficient to have it only computed when search results are returned? Once you have it in the database you can't do a sort on last names any longer (unless you have an extra field for the last name only, which seems a waste of storage space). In this case, I would just (a) leave fields to contain first and last names in the db, and (b) make the "calculation", or rather the string manipulation, in the display code.

In your case, you could do something like this:

(a) in sub modify_record, add a call to another subroutine right in the beginning:

&post_enter_stuff;# for db modification


(b) create individual files for each database, something like "dbname_custom.pl".
Require them after $db_setup is set in db.cgi, and when the other libraries and files are required:

my $db_customfile = $db_setup . "_custom.pl"; # this line before the eval block
require ("$db_customfile"); # when you require everything else

Make sure to add the "1;" at the end of the customization file. Otherwise the "require" won't work.


(c) in each dbname_custom.pl which you have for the various dbs, add this:

sub post_enter_stuff {

$in{name} = $in{firstname} . " ". $in{name}; # example if you want this in the database


}


- That's just one example. As I said, in this particular case I'd prefer not to do the manipulation for the database, but rather for the displayed search results. So I would actually create an html_record for each database and put it into dbname_custom.pl. Then this one would look like this:

sub html_record {
my %rec = @_;
# whenever you want to print the name

print "Full name: $rec{firstname} $rec{name}<br>";


}

In the end, it all depends on what things you'll need to do with your data, and the trick (I guess) is to be able to know as much as possible beforehand what ultimately unforeseeable modifications might crop up.
kellner

thank you! i think that will get me started. the name field was an easy example but not necessarily what i have in mind. hopefully, with your suggestion, i can figure out how to call a routine from html_record etc.

so far, i haven't run into an IF problem that cannot be resolved in db.cgi html record routines globally using field length, field type, or how it's being called (add/modify/display). so once i have db.cgi handling everything, i won't have to modify html.pl for every database. i'll pull out the global, header, footer & at least short-display sections and hopefully the rest can be untouched. so i can modify the cfg file and the appropriate format file -- with all the customizations easy to access and all in one place.