ok.. except for a few things.. (well alot) i am practically done with this mod..

there are some things missing from the version i made for myself.. but i'll be trying to implement them by the end of the week when i'll probably release it..

http://www.pdamania.com/review.cgi?ID=2

and then of course.. what i'm aiming at:

http://www.pdamania.com/sql/review.cgi?ID=2

right now.. the sorting for the Links SQL one is based on ID descending.. so it's in order that they are posted.. i'm going to see what i can do to make it sortable in anyway (viewable on second URL) but i'm gonna have to figure out how to make review.def using the admin

also.. i'm gonna need a cleaner layout..

right now.. a few things that the links sql one is lacking

-2nd and 3rd graph (image/html and html graph)
-a working form
-sorting
-admin
-user total and average

all of them are just simple things.. except maybe the admin.. i haven't looked into that yet.. but i beleive it will be as easy as links2's admin..

also.. links sql 1.1 has Users right? cause i only have links sql 1.02.. i would like to implement review.cgi to work with the users so i'll have to look into that..

jerry

Links 1.1 beta allows you to select the sort order for most pages by setting the sort order and passing it as a parameter to the sort routines.

hmm.. therefore i really need links 1.1

i'm not on the mailing list yet though..

that seems easy though.. since links sql doesn't have dynamic categories.. i'm guessing that is why the sort is hardcoded.. my old category.cgi is VERY similiar to wait that does.. except it builds that automatically..

ie.. if sort = 0 (usually 0 is ID) it will localize a scalar $sort with the value "ID"

then it will see if order is equal to anything.. if nothing or A then a scalar $order with the vaule ASC is localize if order is d.. then $order is DESC

and then it flip flops DESC and ASC if it is either a number or a date.. so you get the highest.. who wants to click on hits and get the lowest one first right?

anyways.. i think for the sort.. i'm still going to go with my way.. it's not like it affects the whole Links SQL.. just review.cgi.. [i'm gonna do it for everything else too.. (on my own)]

jerry

Actually... I'm not sure if you see it, but
the sort order is just part of the 'select'
statement query. By turning the select
statement into a bunch of passed parameters,
the same statement can work for everything,
it just substitutes what's passed to it.

You don't have to hard-code a sort order, just develop your generalized SQL Query, and pass it the parameters you can set in a config file, or from the submit form.


By doing this, you allow the user to decide
what works best for them, and just pass the parameter into the query. The order the
perl routines see the results in is determined by the original SQL query, not by
sorting them afterwards. A lot less need for all the fancy sort routines

yea.. that is pretty much what i did for review.cgi on my own version.. but with links sql.. i am trying to stay more with what links sql uses..

jerry

the code _is_ from LinkSQL

i didn't say it wasn't..

my code for sorting on my sql directory is very different from links.. as it is editable and more dynamic.. there is still a "default" sort like links sql.. but i don't beleive the user can change the sorting of a category..

in my last post. i was refering to that.. and i don't think i want to add it in to review.cgi as it would be something totally not "Links SQLish"..

if you want to know what i am talking about:
http://www.pdamania.com/sql/review.cgi?ID=2

just click on username again.. or click rating.. you can do it for any field.. but i only display those.. (asc and desc.. just click on the link or arrow when on asc for desc.)

that doesn't use links sql at all.. it uses a program i made that has a bunch of links 2 features.. but i don't think i will continue further on it. as links sql is what the target was.. and now that i have links sql.. there IS no point

jerry

<G> Well... the more I go into the program, Alex was right about LinkSQL really being the DBSQL.pm package.

Give yourself a bit more time with LinkSQL and DBSQL.pm and you'll probably change your mind about a few things. I've actually moved a few programs into LinkSQL that I had thought I'd keep separate, just because using the DBSQL.pm package made life so much easier all the way around.

I don't have the time to support stand alone programs, so I'm not going to write them <G>

I've taken some of my stand-alone programs and cut them 90% in size by getting rid of all the parameter processing, file-handling and sorting routines (not to mention Templates routines) that already in LinkSQL.

As long as the interface to the DBSQL.pm module doesn't change, none of my programs are going to need to change as Links develops, and they can grow with it.

It's a heck of a lot easier managing 10 lines of perl/SQL code sent to DBSQL.pm than 120 lines of perl code handling things directly <G>

BTW... Jerry, if you are looking to solve a quick problem (maybe) I've been trying to get the modify.cgi to allow people to enter the url they want to modify, have it check the database, if found, print out the record for them to modify, if not, send them to the add form. I can't seem to pass the parameters to it properly. I've been playing with this off and on, and I know I'm missing something obvious (or I've changed something I don't remember changing).



[This message has been edited by pugdog (edited October 18, 1999).]

that's easy..

you just do a query on the database.. and then get the results as a hash

something like

SELECT * FROM Links WHERE URL = "$theURL" LIMIT 1

and then

&html_modify_form($sth->fetchrow_hashref);

and then in modify form.. i'm not sure if it does it by itself..

yep... i just checked.. just put the field tags into the form values.. like

<%URL%>

gotta sleep
jerry