I'm setting up a site for DJs to post playlists and then have visitors come and vote on their favorite. But I would like to set up a default, so that only one playlist per DJ (registered User) will show up on an initial search. The User would be able to select their default page. There would also be a separate Search box for the entire database.
To see how the site looks and works so far - http://www.tagyerit.com/outlaw
<p>
By the way, this is an awesome forum. I've spent weeks digging through for gems. The hard part sometimes is to know exactly how to phrase the search term. Thanks

Rich

There is a mod in the Resource Center called "Limiting the number of records per user" which may be just what you are looking for.

Hope this helps

Lois, Thanks but that's not it. The closest thing I can think of is some combination of the Validation Mod, and the Short/Long mod. But I don't know enough about scripting to know what to borrow from each.
I want the User (and/or administrator) to be able to select from the records that the User has created.
That one record for each user (with all or most of the fields) becomes the default that would turn up (or be searchable) on a "short" search.
While all records from all users would be searchable on the "long" search.

Thanks
Rich
I'll have to play with the short/long mod some to see if it comes close, but I'm just guessing

I'm unclear on exactly when you want this to happen. Do you want the DJ's playlist to come up when he first logs on? Do you want a link he can click on to get his playlist? Do you want a separate search form?

JPD
http://www.jpdeni.com/dbman/

The playlist would come up with a search form, viewable to anyone - not just the DJ. There will be 2 search forms from a static html page (navigation frame, actually) One search form will show a list from preselected fields AND the designated file. In other words, there would be one result shown from each DJ.

The other search form would show results from the entire database.

An example of how this is probably going to look (though not how it will work) is at http://www.tagyerit.com/outlaw. There you will see the 2 search boxes on the left. The top box offers 4 preselected categories. But I want those categories to only show the one playlist from each DJ. In this case it would probably show all of the viewable fields.
(There's another question coming on this, but I don't know if I should muddy it just yet.)

Thanks
Rich

I still don't understand. (Maybe I'm just dense. )

I need basics. You say "playlist would come up with a search form." There will be a search form on the playlist? Or the playlist will be the result of a search?

"there would be one result shown from each DJ." What is a "result"? A playlist? Or a song from a playlist?

"I want those categories to only show the one playlist from each DJ" This is a little clearer, but I don't think I know how to do that. How would the script know which playlist to show from a given DJ?

"There's another question coming on this, but I don't know if I should muddy it just yet." Please do. Please lay it all out at once, step by step. One of the most frustrating things I deal with here is spending a long time writing code for people and then they say, "Oh, but I want it to do something else, too." Invariably, it means scrapping what I wrote before and starting from scratch. I don't mind spending the time to help, but it does bother me when that time is wasted.



JPD
http://www.jpdeni.com/dbman/

I'm sure you're not dense. I'm brand new to databases, and obviously not proficient with cgi either, so I apologise for getting my terms crossed between disciplines.

Each time after a user (DJ), logs on he's offered the following fields to fill out (I'm putting an asterisk here to indicate the required fields:
DJ(*)
Date Posted (automated)
Genre (* drop down selection list with 4 genres to choose from)
Playlist (*)
Station ID
Broadcast Schedule
URL
DJ Profile
Email

The user (DJ) is free to add new records (i.e. files - not 'record albums') as often as he/she likes (which would typically be once a week). But the goal is to have the DJ (user or administrator) select one set of records, as their 'default'.
Now, there are 2 search boxes that are viewable to the visitor. A visitor, by the way would be anyone who comes to the website and does not have to log on. One of the search boxes should create a list of records, with one record from each DJ showing up. This is what I'll call the 'Playlists Search box'. In other words if the visitor selects the genre 'Calm', all DJs who have 'Calm' playlists will show up, but only one record per DJ.
The other search box is what I'm calling the 'Database Search Box'. This second search box would be able to search through the entire database for any types of matches. So, for ex., if I wanted to see if a specific song or artist has been played by anyone at any time, I would use the 'Database Search Box'.

I guess I was thinking that there might be a way to place a checkbox field, so that when the user (or administrator) checks it, it becomes the default record that would show up on the 'Playlists Search box'. But it would have to somehow uncheck any of the other records.

Before going on, let me interject my other item (the muddyer). This might actually suggest a different approach.
Some of the fields, as you can see, would remain constant from week to week, such as Station ID, DJ Profile, Broadcast Schedule ... Is there a way for the user not have to fill these in each time they added a new playlist? If I could limit the user (DJ) to have just one set of records, but a specified number of playlists (say 8), so that there might be 8 playlist fields (i.e. Playlist1, Playlist2, Playlist3 etc) .... but there would still have to be a way to change which one of these playlists would become the default. ... And I'm not sure if this would be a factor in terms of slowing things down, but these playlist fields are large fields (6000 characters).

Since I know many of the DBman applications have been used for sales inventory, here's another way to look at it. Imagine that a retailer is selling textbooks for 5 different subjects. Chemistry, Math, Physics, Anthro, and Art. And you had 5 publishers in each discipline with 20 book titles per .... Suppose each publisher was running a sale on one item, ( with huge financial incentives for selling that particular title). Then you would obviously want to somehow feature those particular titles ... maybe come up on a Specials Search.

Sigh! well I don't know if I've come any closer to explaining or not, so I better wait and see.

Thanks
Rich

Oh! I get it!! (And, yes, I am dense sometimes. )

This is a job for (dah-ta-ta-daaaaah!) relational man!

You would set up two database files -- one would hold the basic info for the DJs and one would hold the playlists.

First, I'd like you to read my tutorial on relational databases at http://www.jpdeni.com/.../Mods/relational.txt. This will give you an overview of what we're going to do.

I'm not sure right now whether it would be better to put the designation of the default playlist into the "basic info" database or into the "playlist" database. Either way it's going to take a lot of coding. I guess searching would be easier if it was in the "playlist" database.

To "uncheck" the other playlists, when a record is added or modified, if the current record is a "default," then it would go through all the other records by this DJ and change the value of the field to 0 (or blank). Then it would just be a matter of setting the value of a hidden field in the form where you want only the defaults to be returned.

(Pardon me while I think out loud here. If I write it into the thread, I'm less likely to forget what I had in mind.)

Is the DJ field a userid field?

JPD
http://www.jpdeni.com/dbman/

I am now reading (and re-reading) relational.txt with some trepidation. Paragraph 3 warns someone at my skill level from trying. And, it was quite a task, getting through the initial set-up, (Which does work), BUT, I've gone too far to turn back now.

The questions I have before I jump in though:
Would using 2 databases like this slow things down much?
Would the user (DJ) need to fill in 2 separate forms, or do they integrate when he/she is adding?

To answer your question, the userid field is currently different from the DJ field. I'd have to refer to my notes, but I believe I needed to do it that way so that the DJ could enter more than one record. (Or at least I thought that to be the case.), But if I change it so that all the DJs records are contained within these 2 databases, would there be an advantage to making the DJ also the userid field?

Well actually, here's an area that I'm confused about. In the 'relational.txt' where you built your 'item' files, would I create say a field for 6 differently named playlists, (if I wanted to limit to 6), or should I have one playlist field and the DJ would be creating a separate record for each playlist?

Then again, if you think I should turn back, I'll understand.

Thanks
Rich

We can work it out together. I'll let you borrow some of my experience for this.

Regarding the DJ field and the userid field -- is there a chance that any of your DJs could have multiple "basic info" files? IOW, do DJs work for more than one station? (I may be completely off on my understanding of this point, but to my mind, a DJ works for a radio station. ) If not, it would be best to have the DJ field be the userid field.

They would have to fill out two forms -- one for their basic info and one for the playlists. However, you could have them fill out the basic info form at the time they sign up for an account -- a registration form, as it were. Again, this would only work if DJs only work for one station at a time.

In the playlist database, each playlist would have its own record. However, you can still limit the number of playlists a given DJ can enter. (There's a mod for that, too. )

Once we get the DJ info thing worked out, you can build that database. That's the best place to start.

JPD
http://www.jpdeni.com/dbman/

I think it's safe to work under the assumption that a DJ works for one station. If not, there's nothing to stop them from opening a second account, with a new userid. I think your registration form suggestion is a good one. Although there would need to be a way for the user (DJ) to modify their registration information. After all, some DJs do change jobs ...

I spent a little time last night with the relational.txt page and I'm not too intimidated with it. Your instructions seem fairly clear - although I'm not certain if they work the same for the user-friendly html.pl as they do for the original html.pl.



Rich

I think you're right. If they work for more than one station, they can create two userids. (This makes me very happy. )

Yes, they would be able to edit their registration form. No problemo.

I don't think there's any difference between the user-friendly and the default html.pl file when it comes to the relational mod. Just a sec. I'll check it...... Nope.

So start with your DJ info database. (This would be the "one" side of the relationship.) Once you get the basic stuff done, check it all out to make sure there isn't anything you need to fix. Then you can spruce it up a bit, if you want to.

Then, if you want to use the secure password lookup mod, add that next.

The next step is adding the "add record at time of signup" mod. The index for the "limit records" mods is at http://www.jpdeni.com/...ds/limitrecords.html. Pick the one that fits your needs.

Again, test everything before you add anything else.

Once you have those things finished, we can work on the playlist database and hooking the two together.


JPD
http://www.jpdeni.com/dbman/

I'm ready!!!.

The DJ profile database (the one) seems to be in good shape so far -
at http://www.tagyerit.com/cgi-bin/dbman/db.cgi.
Now, I'm ready to create the playlist database (the many)

The goal of the list database (I'm writing this to remind myself as well) is to have one 'date entered field' and one 'playlist field' per record.
The DJ (and admin) should also have the ability to designate one playlist per DJ as the 'default' (or favorite) playlist. The goal here, is for a visitor to be able to view one list per DJ. And I want the DJ to be able to select a new 'default/favorite' each month.
There will be 2 search options for the visitor.
One will allow the visitor to view by genre. In this search there would be one record per DJ showing up, so that is why I want the ability to select a 'default' playlist.
The second search option will let the visitor do a word search that will show up all records that meet the criteria.
Whew!
I hope I spelled this out clearly enough.

Thanks, as always.

Rich

Cool!

Looks like you'll need the followiing fields in your playlist database:

PlayListID (a counter field -- the $db_key field)
UserID (the same name as the userid field in your DJ database)
DateAdded
PlayList
Favorite (a checkbox field with the value "Yes" for when it is checked)

The only thing that concerns me is
I'm not sure how to go about checking to see when the favorite playlist has been changed. Is this something that is absolutely necessary?


JPD
http://www.jpdeni.com/dbman/

Maybe if I give a little more background so you can see my intent, it will help. One of the things that we're hoping to do, is generate a little bit of fun on the site. So the original idea was to have DJs post their playlists and then get visitors to vote on their favorite DJ. Each month then, there will be a new DJ chart for
visitors to vote on. By the way, they would always be voting from the previous months pool. As a musician, this strikes me as poetic justice because it almost turns the idea of Top Ten music on it's ear (so to speak).
Of course I have no idea if I'll really be able to get people to participate, but that's one of my goals.

I suppose that it won't be necessary for the DJ to change it, and I think, from what I've read, that I would be able to set the search function so it would only provide playlists from a given month.
As long as a DJ has posted at least one playlist in any given month, it's not so critical that they remember to select this, as long as the administrator could do this. But of course, there would have to be a way to de-select any previous playlist that had been selected by the DJ.

Since my understanding of the inner workings of the database lead me to believe that this is really all done by magic, I may be way off here. But 2 different existing mods, looked like they could possibly provide some direction, because they allow some form of selecting & de-selecting. I'm referring to the "archive records" mod and the "validate records" mod. As I said, I may be way off.

Obviously one of the goals of customizing the database is to minimize the amount of monthly chores involved for the administrator.

Thanks
Rich

Actually, it's very logical. That is, the commands are logical. What happens between the commands and actually displaying the page -- *that* is magic.

Yes, you would be able to only display the records that were added within a given month. That wouldn't be a problem.

Were you thinking to archive the previous playlists? That would take them out of the current database and place them in a separate one -- past playlists, I guess. Is that what you had in mind?

So, if a DJ didn't add a playlist for the current month (or previous month, however it works), he/she would not be in the running for the voting. Yes?


JPD
http://www.jpdeni.com/dbman/

Just to clarify. Obviously I don't know the limitations, so I'm looking at different possible ways to tackle this.

The archiving would be one way. I just don't know enough about the options to have a preference. You are correct that "if a DJ didn't add a playlist for the current month (or previous month, however it works), he/she would not be in the running for the voting."
But the issue would still come down to the fact that the DJ might list more than one playlist in a month, and therefore would need to have only one Favorite.
Then again (thinking out loud), if I provided the DJ, with say 5 playlist fields a month (ie. playlist1, playlist2 ...) within one database, would that make it easier to isolate one as the "favorite"?
One thing I'm fairly confident is that the DJs that usually post their playlists online, are not the full-timers of commercial radio. They just would never have the time. It's typically college radio, non-commercial and specialty shows.
I'm trying to keep my mind open about the best way to do this, rather than try to force something into an ill-fitting solution.

Rich

We can work around the "Favorite" thing -- I think. Actually, the biggest problem I see is if a DJ did not select any of the playlists as "Favorite." I'm not sure what you would do then.



JPD
http://www.jpdeni.com/dbman/

I think I've got it.
Assuming that I use the 5 playlists in a month approach, I would add one more required field. This would either use a drop down menu or a radio button. At the very least I could label the playlists Week One, Week 2 etc. It would be defaulted to Week One, unless selected by the user.
The trick then is to only display the selected file in the genre search.
Depending on how much magic you've got in your wand, and that I'm not totally over-optimistic - One other thing that would make this even cooler, is if in the displayed result, instead of reading as "Week One", it read "Week of 'dateadded' ".

How'd I do?

I really don't know, I'm afraid. I need you to decide what it is that you want and then I'll try to help.

I'm really sorry, but I'm on the edge of burning out right now. Overload!!!!!!![ain't no smilie that fits]

JPD
http://www.jpdeni.com/dbman/

Time to simplify then. Sorry I've taken so much time.
The 'favorite' category can be optional, or I can skip it altogether.

Now, I'm sitting here with 2 sets of database programs, and I need to tie them together. I tried to make the modifications that you suggested in relational.txt
The first place I seem to be stuck is on trying to access the 'playlist' from the 'profile' database. The message I'm getting is "invalid/expired user session".
Let me know what other info I need to give to troubleshoot.

Thanks (I really am grateful)
Rich

Rich, I really am sorry. I'm not doing very well right now on a whole lot of fronts. As long as we take this one step at a time, I think I can handle it.

What code did you add to the profile html.pl file in order to have the playlists appear? Let's get the "invalid/expired user session" thing cleared up.

JPD
http://www.jpdeni.com/dbman/

JP, No need to apologize. You've been great. Let me know any time you need to stop.
Health ALWAYS comes first. Or else it aint worth it.
Thanks
Rich

Here's the change I put in sub html_footer:
# on 7/1/00 I substituted the following 2 lines
# print qq!| <A HREF="$db_script_link_url">Home</A> !;
print qq!| <A HREF="$db_script_link_url?db=playlist&uid=$db_uid">Playlist</A> !;

In case it's relevant - Here's what I added after sub html_record:

# Tell DBMan to look in the other database
&switch_to_playlist;
# Look for items added by this user
undef %in;
# To clear out any previous search terms
$in{'DJ'} = $rec{'DJ'};
# Sort the results by the DateAdded field, in descending order
$in{'sb'} = 6;
$in{'so'} = 'descend';
# Set the maximum number of hits per page to a large enough number to
# guarantee that all records will be returned
$in{'mh'} = 100;
# Do the search
my ($status2,@hits2) = &query("view");
# If there are any search results
if ($status2 eq "ok") {
# Calculate the number of records returned
my ($numhits2) = ($#hits2+1) / ($#db_cols+1);
# Set up a table for the display
print qq|<table>|;
# Go through each hit and print out the results
for (0 .. $numhits2 - 1) {
# Break the array into a hash for printing
%rec2 = &array_to_hash($_, @hits2);
# Print out the link to the full item record
# Note that I am using $db_script_url and *not* $db_script_link_url.
print qq|
<tr><td>
<a href="$db_script_url?db=playlist&uid=$db_uid&PlayListID=$rec2{'PlayListID'}&view_records=1">$rec2{'extra-word playlist'}</a>
</td></tr>
|;
}
print qq|</table>|;
}

# Tell DBMan to go back to the original database
&switch_to_profile;
}

OTHER NOTES:
Shared Files
auth.pl, db.cgi, default.count, default.log, default.pass

Playlist files and fields (caps shown as appropriate)
playlist.cfg, play_html.pl, playlist.count, playlist.db
DJ , PlayListID, DateAdded, Playlist, Favorite

profile files and fields
prof_html.pl, profile.cfg, profile.db
DJ, Date_Posted, Genre, Station_ID, Broadcast_Schedule, URL, DJ_Profile, Email

Here it is!

print qq!| <A HREF="$db_script_link_url?db=playlist&uid=$db_uid">Playlist</A> !;

should be

print qq!| <A HREF="$db_script_url?db=playlist&uid=$db_uid">Playlist</A> !;

The "$db_script_link_url" includes the "?db=whatever&uid=$db_uid" part already in it. By using that variable, you've got it twice.



JPD
http://www.jpdeni.com/dbman/

Great! That's one down.

Next problem. When I log on and switch to Playlist, there is no place that shows the "Add" in the footer for playlist.
I would assume this is connected to using the following 2 mods limitrecords1.txt and limitrecords3.txt The first of these Mods has instructions to not show the "Add" link in the footer. So I tried to 'comment' that part out, but no luck.

In profile.cfg (the one) permissions are set
# Permissions a new signup should get.
@auth_signup_permissions = (1,0,1,1,0);

I tried this with a 1 in the second 'add' position but that didn't do it.

In playlist.cfg, it's set
# Permissions a new signup should get.
@auth_signup_permissions = (1,1,1,1,0);

What have I missed?

Thanks
Rich