Ok, here's is what I want to do...

I am creating a host database where companies can come and add all of their hosting plan information...basically they will enter all their company information when they register(so there will need to be more fields than just user/pw/email). Then they can then login and add/modify/delete their hosting plans.

So basically the question is

1) Is it possible to collect more information during registration, then be able to view that information on the web page.

2) Does LinksSQL have a links.def like Links 2.0 so it is easy to edit the fields you would like to have? If so, does the registration have its own definitions so I could just add the extra fields there?

Hope I explained it well enough!



Until next time...

Ryan

http://links.innovationstudios.com/

1) Yes.
2) Yes...but the administration is TOTALLY web-based through web forms...so, no need to touch the nuts and bolts files within LINKS SQL.

Read more about the Product!

Regards,

Eliot Lee

Ok,

One more question...

I did the walk through and checked through the site and admin but couldn't find this feature:

I want to let users be available to view user's registration information. First, does Links SQL already let you include registration information on detailed pages? Like <%username%>? Also, it would be hard to create a CGI file to view user information? Like user.cgi?user=<%username%> and it pulls up all the registration information?

Thanks a lot!!!



Until next time...

Ryan

http://links.innovationstudios.com/

There is no out-of-the-box USER detailed page. But GT is working on this and should have it available in future releases. It would not be complicated to adapt the detailed pages for Links to Users though. All you have to do is copy the dynamic LINKS DETAILED page Mod, which is referenced quite a few times in the forums and also listed at the Links SQL FAQ web site maintained by pugdog -> http://www.linkssql.com...and all you have to do is change the DBI object to the USERS table rather than the LINKS table.

You can see my profile in my Member's web site:

http://members.anthrotech.com/...serdetail.cgi?ID=103

And in terms of database design and programming, your example of using the USERNAME is not very good. You need to use UNIQUE parameters like the PRIMARY KEY of tables to show UNIQUE records. The problem with using the USERNAME as a parameter is that you could have two users, like BOB and bob...if you try using your example, the script would error out or show both records in the same output web page.

Regards,

Eliot Lee

You've changed the look of your site a bit since the last time I looked.

I like the way you've laid it out, and have the options clearly available to the users.

It's not hard to allow editing the user database, to display it you can use the detailed.cgi as you pointed out, then modify the add and modify scripts to use the 'user' table not the links table.

The problem comes in in 'security' where you don't want a user to be able to change their validated email address (so you can always reach them) without a re-verify of the email address.

It also comes in if a user wants to delete/change their user name.

If a user who owns a link deletes their user account, it would "break relation with foreign keys" in the Links table, and those link records would (theoretically) be deleted along with the user.

The same way, if you delete a category without first moving the links, all the links in that category will be deleted (unlike Links 1.x where the links just became orphans).



PUGDOG® Enterprises, Inc.
FAQ:http://LinkSQL.com/FAQ
Forum:http://LinkSQL.com/forum

pugdog,

Thank you very much...I am close to upgrading the Career Connection (Resume and Job Postings databases) to work with Links SQL with one common login for the entire site(s).

I have installed many referential integrity error catch codes in the admin.cgi and also in other user driven deletion scripts.

For instance, all the user deletion scripts (for links, banners, etc.) will delete records in related tables and in a logic manner that will not pose foreign key errors.

Also, if users delete their accounts, the foreign key of "Links" and "Banners" tables are updated to the MASTER ADMIN account based on the USERID of the MASTER ADMIN account. This also happens in the ADMIN.CGI script, so that if the ADMIN deletes a User account for various reasons, their LINKS/BANNERS, etc. are updated to the ADMIN USERID.

The one tricky thing I've come across is maintaining contexts of forum discussions. It is difficult to simply delete a post out of the forum script I am testing...it loses context of other messages, so I will have to come up with a system for the forum script that will maintain context when users are deleted.

Oh, and also, I don't allow users to update their user account information unless their account is Registered.

See ya...

Regards,

Eliot Lee

Cool...

But my point with the editing the account is this:

User registers with "user@goodemail.com"

Then, after he validates it, he changes his email to "user@bogusemail.com"

Then he causes problems. He's registered, validated, and still has a bogus email address and user profile now. On a small site you may remember him, on a large site, it's not possible.

WWWThreads keeps the "sign up" email stored in the database, then allows you to change the "contact" and "visible" (I forget the exact fields) email addresses once you are registered. This is a partial solution. I still like to keep the original email, but also the current email should always be re-validated if the user changes it.

Users do legitimately change email addresses, which would make the original Email pointless, although if the user does cause problems, that ISP should have some record of who he/it was that owned that account at that time.

PUGDOG® Enterprises, Inc.
FAQ:http://LinkSQL.com/FAQ
Forum:http://LinkSQL.com/forum

Ah, I see your point...But I would rather have users be able to edit their email address rather than having to manually update records, which I had to do with DBMAN and other apps. The costs or risks of having people put in bogus email addresses is not that much compared to having to manual edit records.

And now since my host is sending me mail server error messages, I can delete out fraudalent accounts, of course, after making double sure that the email address is bad.

Regards,

Eliot Lee

RMS,

It might work better if you would think of the various hosting plans as "links", and collect additional information (size, price, polices, standard features, etc.) on each of these "links".

Your "users" would be two classes, people coming to the site to use your content (view, rate, review, etc) and those coming to add content to your site (hosts). If needed, you could add a T/F column to the users to determine if they are validated to lists hosts.

Some of this will also depend on how you plan to make your money. Advertising to users or selling listings and/or upgrages to hosts. Selling listings and/or upgrades would require some extra thought and careful planning to make things run smoothly.
--
Rob Van Deren