Gossamer Forum
Quote Reply
Review.php
Hi All,

I wanna get the reviews going on my copy of Links SQL, and I am gonna make an addon to do this in PHP.

The addon won't effect the ratings, it will just simply take the reviews and show then, no fancy graphs and things like that which Jerrys one will have - but my hosts won't install all the things I need to do that, so... yeah Smile

Anyway - The reason I come here is to ask what sorta table layout I should use, cause I can't really think of a good one.

I was thinking I have..

Table: Reviews.
Column: ReviewID, INT, AUTO_INCREMENT,
Column: ID (the one being reviewed), INT,
Column: TheReview, TEXT,

Just leaving it like that I guess Smile

Easy enough to make then. Have a form saying review.php?id=3

Thats added, and then when you call readreviews.php?id=3

It calls all of the reviews, and prints them out neatly in tables etc...

Is that the best way to do it, I don't have that much of a problem with the coding anymore with PHP, its just the way to lay it all out I find difficult Frown

------------------
Michael Bray
Review your webhost or find a new one.
www.webhostarea.com
Links SQL User
------------------




Quote Reply
Re: Review.php In reply to
I would agree this is something that would be easy, and possibly faster to code in PHP. The only thing is, that every time the review page is looked at, the system has to generate the page.

If your page views for the reviews don't occur very often, it's probably a good thing.

Likewise, if your reviews change regularly, or are very active, it's probably a good thing.

If your reviews rarely change, but are read often, then statically building the pages would give better performance.

You probably want to track other information in the table -- a numerical rating, perhaps the ID of the reviewer, etc.

The link to the database should the the LinkID (ID in the Links table) since that is unique, and will never change. If the record is deleted, you'll be able to delete the reviews asociated with it fairly easily.

The reviewer ID should be the ID in the user database, since you can yank the updated user info out of that database when you print out the reviews (if their email changes, for example).

If you make the first field an auto-increment field as you do, you can use DBSQL.pm to access the database from inside links. That will make .cgi/perl coding easier.

Think about what you would want in the record to appear on the page, or to be able to be associated with the rest of the links database.
Quote Reply
Re: Review.php In reply to
OK,

I know a couple of people here are interested in getting the reviews going, so I'll keep you up to date with this.

I have done the code now to add the review, and reading it will be a sinch, right now its using the following SQL table...

Code:
CREATE TABLE reviews (
review_id INT DEFAULT '0' NOT NULL AUTO_INCREMENT,
link_id INT DEFAULT '1' NOT NULL,
review_name varchar(150) NOT NULL,
review_email varchar(150) NOT NULL,
thereview TEXT NOT NULL,
PRIMARY KEY (review_id),
UNIQUE id (review_id)
);

I am not making it produce fancy graphs, its gonna be fast and simple. You'll be able to access the table through editor.cgi

Reviews are not validated. I am gonna make it so that the emails are validated, but I'm not that sure how to do that with PHP yet Smile


------------------
Michael Bray
Review your webhost or find a new one.
www.webhostarea.com
Links SQL User
------------------




Quote Reply
Re: Review.php In reply to
Just a few things...

PHP is a scripting language. PERL is far more powerful, and don't get caught up in the "ease" of using PHP. PHP makes accessing an SQL server (MySQL) easy, and makes creating dyanmic pages from that easy. But, it's lacking a lot of things that a CGI program can do. Once you attempt to call PHP as a cgi, you lose any advantage.

PHP has some advantages in that people who don't want to learn PERL have started with PHP, and there will be some scripts and tools, etc available -- but anything in PHP can be written in PERL -- especially for Links SQL.

I see you are using Ultraboard -- I looked at it, and they had a really neat idea, and product, but by charging for it at this stage, they've created some peoblems for themselves. They should have open sourced it, under GNU, and allowed it to grow. They should have concentrated on support/customization not charging -- what they've done is limited the audience -- look at LinkSQL vs Links 2.0 -- and the sheer number of people/mods/etc between the two --- even though Links SQL is easier to alter.

My point is, before digression, is load something like Phorum -- which is a PHP3 based Forum -- and note the differences between what it can do on the back end and what WWWThreads and UltraBoard can do.

Your page layout may be easier, but other things are much more complicated.

I'm not sure PHP can offer anything emb_perl and mod_perl can't do -- and do better.

This isn't a religious thing Smile I've bought _all_ the PHP books, I've tried _all_ the available PHP programs (free ones) and I've kept going back to PERL (not even emb_perl).

I had really high hopes for PHP, but I think for sites like Links sites, that are already cgi/perl based, PHP is adding a level of complexity and support problems that are unnecessary and don't provide any benefits.

I don't know enough PHP to be of help to you, really, but as a test, I'll match what you do in PHP in perl, and since I'm _not_ a perl wizard (I boiler plate, cut/paste, etc what works from routine to routine) It's not an unfair match. We'll look at the code, and see which is better and why. I can run PHP _and_ mod_perl (I'm not running emb_perl) so if you want, I can set up your mods on the FAQ site as a new point of entry, so there are no server-related speed differences either.

I'm interested, because I _thought_ a PERL back end, and a PHP front end to the site would be the best of both worlds, but I have never been able to make it work even in a simple form.

I use the PHP admin program -- only because I can't find one in perl. When I compile in the new WebAdmin program, maybe I'll have found one Smile It has MySQL support now, but it's still a first release.


Quote Reply
Re: Review.php In reply to
Michael,

I don't currently have any use for it for my site, but I know at least one other Links SQL user who does.

Dan
Quote Reply
Re: Review.php In reply to
To do the validation, you'd best look at the code for the add/modify.cgi programs.

You'd want the review added to a V_Reviews table, and then put a link in the Admin to use that table in the "Validate" routines.

You might have to clone the validate routines to make sure they update to Reiews, not Links. I have a feeling that portion is hard coded somewhere in the routines.

I know you can add tables and use Editor.cgi on them without a problem.

Or, you could write a new routine to insert the review in "unvalidated" state with a field set to "0".

When you do a search, you only list reviews that are "1" so the SQL statement would contain a statement "AND VALIDATED="1"

That way, you could have unvalidated='0', rejected-'2', pending='3', etc.

All you'd do in the admin is flip the flags on the reviews you approve of.

The advantage of perl for this, and using DBSQL.pm is that if you use the .def files, you can define the field formats and lengths for the text fields, and limit them beyond what MySQL will do.

Quote Reply
Re: Review.php In reply to
I guess adding the validation to the tables is easy enough. If the validate routines are in Perl, are the regexes the same in PHP?



Hehe,

http://www.webhostarea.com/php/displayreview.php?link_id=3

Right now its looking pathetic, but I am working on the backend part of it at the moment. I have the addform on my computer, so when I upload that I let you add reviews to test Smile

Will anyone else use this? Its in PHP, so some of you may not be able to use it (PHP is sooo much like Perl, but I reckon its better...). I am gonna do page.cgi in PHP later I hope if I get enough time.

I mean, I have all the code commented, but if your all waiting for Jerrys one I won't make any documentation or anything like that. BTW - It'll look better, its just that I haven't started on the cosmetic side of it yet.. It'll probably just grab the header and footer files from the templates folder and wack them in...





------------------
Michael Bray
Review your webhost or find a new one.
www.webhostarea.com
Links SQL User
------------------




Quote Reply
Re: Review.php In reply to
I think you'll find that for accesssing things like MySQL tables etc, and just printing the results that PHP is faster.

Anyway - My PHP code isn't the best, but hopefully if you match what I do, mine will be faster Smile This is my first PHP Script btw, I have made test scripts and all that, but this will be the first thing I use, so the code might not be the best Smile



------------------
Michael Bray
Review your webhost or find a new one.
www.webhostarea.com
Links SQL User
------------------




Quote Reply
Re: Review.php In reply to
BTW,

For the forums, like UltraBoard which create all the topics dynamically, what can they do which PHP can't? Check out this forum... http://forums.vb-world.net/ - Its gonna be released soon, and I think its the best one around.

Log visits, edit messages, user database, cookies, all can be done with PHP... And can be done with ease. Once its done, you can use PHP or Perl to access it - Cause its all SQL Data -> Its simple to use.

I don't see why you can't use the Perl backend and PHP front end. The actual data won't have a clue what language is used to access it -> And for somethings one language will benefit over another.

I am sure I could use Perl to validate the reviews and then just use PHP to grab em and whack them on the screen.

I guess the reason I am using PHP is I don't mind having everything made dynamically, cause the database I use is added to every day, and built every day -> It would be easier just saying yes or no to 5 links, clicking OK, and there on the site, same with the reviews.

Anyway -> Once I get the Zend Optimser setup, you'll come crawling to PHP Wink



------------------
Michael Bray
Review your webhost or find a new one.
www.webhostarea.com
Links SQL User
------------------






[This message has been edited by Michael_Bray (edited March 27, 2000).]
Quote Reply
Re: Review.php In reply to
why not just do it in perl?

http://64.6.238.208/review2.cgi?ID=1002

pdamania.com has moved to a dedicated server.. so all the stuff linked to it is down right now cause i haven't uploaded my site yet..

umm... the graph is down... just look at

http://64.6.238.208/graph.cgi?ID=1002

anyways.. some of you know and some of you don't know.. but I'm not going to be doing much more Links/Links SQL stuff for awhile..

too much other stuff to take care of first..

argh.. bye

------------------
Jerry Su
Links SQL User
------------------
Quote Reply
Re: Review.php In reply to
Yeah,

I was just gonna wait it out for your one, but I started learning PHP and I figured this would be quick and easy for what I need, which is a basic review script.

I thought you had died or something - But I am guessing you are in your last year of school or something like that, which is more important!

I like my review script Smile I can strip out all HTML and Javascript etc with one line of code which is built into PHP, You honestly reduce the code down by 50%, and its much eaiser to use Wink

The admin section of it will be hard though, bloody hard Frown

------------------
Michael Bray
Review your webhost or find a new one.
www.webhostarea.com
Links SQL User
------------------




Quote Reply
Re: Review.php In reply to
Hi Michael,

Looks promising! One word of advice, if you are not going to search on these, I would just have an 'isValidated' = 1 or 0 flag to tell if it's validated, and not use a separate table. It's a lot of extra work. =)

Cheers,

Alex
Quote Reply
Re: Review.php In reply to
K,

Sorta stuck, I am making my own user database ( I just wanted to... I know theres a built in fast one in perl, yadda yadda yadda Smile).

Anyway, heres a snippet of the code I'm stuck on, it should work... Can't figure it out.

Code:
// Connect to MySQL and choose the Database, kill the script if there is an error.
$mysql_link = mysql_connect($hostname, $username, $password) OR DIE("Unable to connect to database");
mysql_select_db("$dbname", $mysql_link);

// Make sure they are registered...

// Make the SQL Query.
$query = "SELECT * FROM reviewusers WHERE username = '$username'";

// Now lets get the result and split it up into some variables.

$mysql_result = mysql_query($query, $mysql_link);
while($row = mysql_fetch_row($mysql_result))
{
$username1 = $row[0];
$theactualpassword = $row[1];
$emailaddress1 = $row[2];
$joined = $row[3];
}

Is there a syntax error, the problem is that

$theactualpassword is not assigned the variable, its left blank Frown

BTW - There are 2 tables now... Userdatabase, Review Database -> Its gonna be good when its finished...

You'll have a new appreciation for PHP when it is Smile
Quote Reply
Re: Review.php In reply to
I'll do that. I'm also adding a bit more on the user side, well, changing the name to username and adding a password so that they can edit there reviews.

I was gonna make it add them to the newsletter automatically, but I thought I better not Smile

------------------
Michael Bray
Review your webhost or find a new one.
www.webhostarea.com
Links SQL User
------------------




Quote Reply
Re: Review.php In reply to
This is a good example of why staying with perl, and going through the DBSQL.pm module is a good idea.

Code:
while($row = mysql_fetch_row($mysql_result))
{
$username1 = $row[0];
$theactualpassword = $row[1];
$emailaddress1 = $row[2];
$joined = $row[3];
}

Right now, you are having to remember which array position holds what value. This is very prone to errors, and is not very portable. If you used anonymous hashes and references, such that you asked for a value as $row('Column_name') you'd be much less prone to errors, and have much more readable code.

I've avoided using the DBI calls, since they are encapsulated so well into the DBSQL.pm.

There are very serious advantages in _not_ coding the SQL queries as PERL/PHP calls, but keeping them as SQL queries that are accessed by a PERL/PHP method.

In answer to your specific question... It looks like you are trying to access the 'C' interface to MySQL. The mysql_select_db call has the format:

int mysql_select_db(MYSQL *mysql, const char *db)

or a use of:

result = mysql_select_db(&mysql, "newdb");

What language are you using? Perl or PHP?

You _should_ _really_ get the MySQL & mSQL book! It has a list of all the functions, features, calls, etc, for C, perl, Java and PHP.

Quote Reply
Re: Review.php In reply to
Its all PHP,

Not a line of any other code yet. I haven't looked at the code for the damn thing yet today...

I got the MySQL & mSQL book -> Its useful Smile I want to somehow get DBSQL.pm involved, however I want to stick with PHP as much as possible.

------------------
Michael Bray
Review your webhost or find a new one.
www.webhostarea.com
Links SQL User
------------------




Quote Reply
Re: Review.php In reply to
Got the code working,

I would show the code here for the FAQ, but right now the codes not the way I want it yet, and I don't want it seen till its "good" Smile.

http://www.webhostarea.com/php/displayreview.php?link_id=3

That works, and all I need to do is add some more fields to the user database, and make it look a bit better Smile

Alot more information is stored in the tables, I just haven't printed it all on the screen yet Smile

------------------
Michael Bray
Review your webhost or find a new one.
www.webhostarea.com
Links SQL User
------------------