What data/variables are most required by DBMan.cgi to be passed to it from a web page?
Taking into account authorization, etc. What hidden fields are required?

From what I see so far it looks DBMan.cgi needs at the very least:
______________
<form action="$db_script_url" method="POST" name="form1">
(The above is needed in one form or another )

<input type=hidden name="db" value="$db_setup">
(to tell DBMan.cgi the database )

<input type=hidden name="uid" value="$db_uid">
(to pass the auth data )
_________________

I am now attempting to use Links2/Template generated web pages to call DBMan.cgi and need some feedback on this from anyone

Thanks
TimRyan




[This message has been edited by timryan (edited August 12, 1999).]

[This message has been edited by timryan (edited August 12, 1999).]

The three fields you listed are required for every form in DBMan.

The other thing DBMan needs is the action input, which is within the submit buttons on the form.

And, of course, the form fields.


------------------
JPD

Quote:
_______________________
The login procedure may be the downfall of your DBMan/Links marriage.
________________________

Nah!... it may put a "wrinkle" in the marriage, but so far I find it working out just fine.

I got DBMan to read/write/modify, etc the Links.db with no trouble. Actually, I believe what we have so far works on the important ends.

At this point I just would have to use DBMan on everything that required the add,modify, delete end. On the searching end I would use links2 for that just the way I have it set up now; with templates and nphbuild.

On the surface this tested just fine. So, I am at the point of the project where I thought I might make life simpler for handling the html customization. Templates is the way to go (in my opinion). Takes a while to learn but the sky is the limit on what you can do with the "looks" of your site.

It would not be good to make a seperate templates mod for DBMan. (from what I read above you will agree). Best to have one Template mod that works with both. Then just put a "links_template" and a "dbman_templates" directory for each.

I am BIG on automation and "one-time" maintenance, just like you mention above Why do twice (or more) what you only need to do once.
TimRyan

TimRyan,

Looks like things are coming along nicely. If you need assistance with implementing some of the advanced email notification and sending procedures I have in my Classified Ads DBMAN program, let me know....

That seems to be another key to the puzzle that you may want to include in your project. I would say that a majority of the twenty people that contacted me with regards to my Classified Ads program, they requested more advanced email notification systems.

Let me know.

Keep up the great work.
Regards,

------------------
Eliot Lee
Founder and Editor
Anthro TECH, L.L.C
http://www.anthrotech.com/
info@anthrotech.com
==========================
Coconino Community College
http://www.coco.cc.az.us/
Web Technology
Coordinator
elee@coco.cc.az.us

Thanks JPD,
This confirms what I have researched so far. Felt good to have a second confirmation.

I spent a good part of the evening looking over DBMan and Could not "exactly" locate the "travels" of the "$db_uid" as it seems this is the variable I will have to pass from my links-template-generated web pages. I see how I can grab/pass "$db_setup" and that is easy because it is a constant and can get that from dbman.cfg.

But, I could use some insight/ideas on passing $db_uid around as it changes on each login (from what I see).

See, the problem I think I am running into so far is that the current dbman web pages are on the fly in dbman so they can easily pass the variables on each pass through.

However, because I will be using hard coded (links/template generated) web pages I have to figure out how to pass that $db_uid around. I have no problem on the links side (so far doing all this). I just have to get more familiar on the auth picture part of how the userid and password is handled in the variable passings, etc.

I am sure that some of the html will have to be on the fly generated but I just have to determine what can and what can not be static.

Actually, something on the order of "The Birth and Life of a login" would be helpfull.

Any ideas on this from anyone would be helpfull
Thanks
TimRyan
PS> JPD, love your site at: http://www.jpdeni.com/dbman/
I am taking it a "nibble at a time" when I can squeeze in the coffee break time



[This message has been edited by timryan (edited August 13, 1999).]

The login procedure may be the downfall of your DBMan/Links marriage.

Yes, the $db_userid changes with every login. It's the username of the currently logged-in user.

Here's the "birth and life" of $db_userid in a nutshell:

A user logs in with his username and password.
The script goes to auth.pl, sub auth_check_password.
In this subroutine, the username and password are compared to entries in the password file. Then a random number is appended onto the username, with a . in front of it. For example, if I were to log in as "fred," the result might be "fred.9876543456789". This becomes the $db_uid that is in each of the forms. A file is created in the auth directory with a name that corresponds to the uid.

Then the script moves down to sub auth_check_permissions, which again looks at the password file to see what this user is allowed to do.

Now the script goes back to db.cgi, carrying with it the whether or not the login went through ok, the $db_uid and the permissions.

The $db_userid is derived from the $db_uid by chopping off everything from the . on. So that "fred.9876543456789" again becomes "fred".

So fred is now logged on to the database and he wants to do something. Every link in the footer includes his $db_uid. It may not be obvious that it does, though. The links use a variable $db_script_link_url, which consists of
-- the url to db.cgi
-- the name of the database
-- the $db_uid

Let's say that fred wants to add a record. He clicks the add record link. The first thing the script does is check him out to make sure he's okay. Again, it goes to auth.pl, sub auth_check_password. But this time he isn't logging in, so instead it looks at the auth directory to see if there's a file in there that starts with "fred." If there is, the script knows he's already logged in, so it goes to check his permissions again. And then reverts back to the db.cgi script.

Whew! The way I learned about DBMan was doing pretty much what I did above. I call it "playing computer" -- I follow the steps that the computer goes through for each command.

Thank you so much for your compliments on my site. I appreciated your other comments about the colors too. (I guess my BA in psychology did do me some good! ) There is a lot of info there. I spent a number of months working on it and, of course, it's still not completely done.






------------------
JPD

Thanks JPD, I will read (and re-read) that nice "tutorial"

How about using server-side includes for the dynamic parts of the web page? Just a thought. Comments? I have not used ssi for months so I would have to read up again to refresh the old brain

Also, do you (or anyone else) know of anyone who has attempted to putting html.pl into seperate *.html files? This would be usefull for some other ideas I have. (yes, I am using the "User-friendly" html.pl, thank you )

Thanks
TimRyan




[This message has been edited by timryan (edited August 13, 1999).]

I don't know anything about SSI. (My ISP won't let me use them, so I've never had an opportunity to play around with them.)

I don't know of anyone who has tried creating *.html files. (I can see where you're going! ) On my site, I went the other way with Links, eliminating the css and the templates and putting all the formatting into the site_html.pl file, just like I did in DBMan's html.pl file. In fact, with my DBMan, even though I have two different databases working on the site, I only have the formatting in one place. I created an extra file -- I call it "format.pl" -- which includes all the page formatting and all of the code that the two html.pl files have in common.

One of my own quirks is that I abhor repeating data if I can get away from it. I'm not even real happy about having to keep the formatting codes in both Links and DBMan. (I may figure out a way to merge them, though.) I'm really aware of limitations on webspace. I have a lot of things I want to do with my site and if I run out of space, I'll have to pay for more. (Read: I'm cheap!! ) Also, the more files that have page formatting on them, the more things you have to edit when you make a change to your site. I always forget something!


------------------
JPD

Looks like you're coming along well, Tim.

I had implemented something sorta similar on another site of mine, but on a smaller scale. When people add a URL to their record, it is automatically added to the links.db, in the appropriate category. Then I just have to go build the Links pages. (Although this one uses the old version of Links, so I'm going to have to update it soon.)

Congrats on your progress. What will we call this new incarnation? DBLinks? LinkMan?


------------------
JPD

JPD,
Sounds interesting. I would like to see the code of what you did there Might be helpfull on giving me some other ideas to resolve which direction to take.

I am still pondering on what would be easiest route. I was going to start out with the add part first.

Also thought of the possabilities of writing a cgi that when called (based on data passed ie, add/delete/modify) would pull in the appropriate *.html (links templated web page) and then append the hidden data, and other code it needed and spit out the final product.

Sort of on-the-fly with templates type thingy I wanted to try and stay away from ssi if I could as not everyone has that option

Anyway, would like to see what you did above if you did not mind sharing the logic for me to have a look see Worst that could happen is I learn something from it.

Eliot, thanks I will keep that in mind when I get to that part. I was thinking about what you say the other day... so it is on the back burner simmering I am doing all this on my home/office (win95/appache) for speed and do not have my email part set up yet. So that all will come into play when I finally get done and go online.

TimRyan



[This message has been edited by timryan (edited August 13, 1999).]

Sure.

Boy, this code is ugly! I've sure learned a lot since I wrote it.

This is the exact code I am using and I want to explain a little bit first. My primary website is support for parents who have lost their only child. When they come to my site, they can add a memorial to the site, which is a record in the database. I have links to memorial websites with the record and on my Links page, hence the duplication.

I also made some changes to the links.db structure, but I'm sure you can recognize what's going on.


I don't even have a definition for $LOCK_EX. Ugly code!!!!!


------------------
JPD

Thanks JPD,
Nothin's ever ugly when it comes to programming. Just another way of doing things, thats all. Personally I like plain-jane and simple when it comes to code. It makes it much easier to debug and understand

I will look over what you have, thanks for sharing the experience

TimRyan