Figured out a simple way of doing this monster.
By using list()=explode() works perfectly.
The problem I have now is, getting the variable I need to correspond to the
clicked link.
<li> <a href='#' class='basic'>A FOOL IN LOVE<?php $show=$a[1]; ?></a><br>
Ike and Tina Turner </li>
This way works fine, except that $show takes on the value of the last item
given.
Jerry Stuckle Messages: 2598 Registered: September 2010
Karma: 0
Senior Member
On 2/18/2011 8:57 PM, richard wrote:
> Figured out a simple way of doing this monster.
> By using list()=explode() works perfectly.
>
> The problem I have now is, getting the variable I need to correspond to the
> clicked link.
> <li> <a href='#' class='basic'>A FOOL IN LOVE<?php $show=$a[1]; ?></a><br>
> Ike and Tina Turner</li>
> This way works fine, except that $show takes on the value of the last item
> given.
>
> Just how is this done properly?
You can't. Such a link is local to the browser; no request is made to
the server.
As others have told you - you need a browser-side solution. That is not
PHP.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. jstucklex(at)attglobal(dot)net
==================
"Jerry Stuckle" wrote in message
news:ijnd59$fci$1(at)news(dot)eternal-september(dot)org...
> You can't. Such a link is local to the browser; no request is
> made to the server.
> As others have told you - you need a browser-side solution.
> That is not PHP.
I would think a server-side database would be most appropriate for this. The
potential amount of information may be several hundred megabytes, while the
information to be presented to the viewer in the browser is only a few
kilobytes, or a bit more if images or sound clips are included. That's why I
had suggested PHP and an SQLite (or MySQL) database on the server.
It appears that this is organized with a separate web page for each decade
and/or the starting letter of the artist, and finally presented as
individual web pages for each artist. Since the website for just Roy Acuff,
for example, is 2173 lines of HTML with a lot of excess blank lines, I think
these web pages may be generated dynamically, rather than static. Here's
that example: http://www.oldies.com/artist-view/Roy-Acuff.html
Jerry Stuckle Messages: 2598 Registered: September 2010
Karma: 0
Senior Member
On 2/18/2011 11:15 PM, P E Schoen wrote:
> "Jerry Stuckle" wrote in message
> news:ijnd59$fci$1(at)news(dot)eternal-september(dot)org...
>
>> You can't. Such a link is local to the browser; no request is
>> made to the server.
>
>> As others have told you - you need a browser-side solution.
>> That is not PHP.
>
> I would think a server-side database would be most appropriate for this.
> The potential amount of information may be several hundred megabytes,
> while the information to be presented to the viewer in the browser is
> only a few kilobytes, or a bit more if images or sound clips are
> included. That's why I had suggested PHP and an SQLite (or MySQL)
> database on the server.
>
<snip>
> Paul
Paul, the problem is that's way beyond Richard's capabilities. I will
give him credit for trying, but his understanding is quite limited.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. jstucklex(at)attglobal(dot)net
==================
On Fri, 18 Feb 2011 23:15:23 -0500, P E Schoen wrote:
> "Jerry Stuckle" wrote in message
> news:ijnd59$fci$1(at)news(dot)eternal-september(dot)org...
>
>> You can't. Such a link is local to the browser; no request is
>> made to the server.
>
>> As others have told you - you need a browser-side solution.
>> That is not PHP.
>
> I would think a server-side database would be most appropriate for this. The
> potential amount of information may be several hundred megabytes, while the
> information to be presented to the viewer in the browser is only a few
> kilobytes, or a bit more if images or sound clips are included. That's why I
> had suggested PHP and an SQLite (or MySQL) database on the server.
>
> Here is a website page that is similar to what richard is doing:
> http://www.oldies.com/artist/browse.cfm/decade_1960.html
>
> It appears that this is organized with a separate web page for each decade
> and/or the starting letter of the artist, and finally presented as
> individual web pages for each artist. Since the website for just Roy Acuff,
> for example, is 2173 lines of HTML with a lot of excess blank lines, I think
> these web pages may be generated dynamically, rather than static. Here's
> that example:
> http://www.oldies.com/artist-view/Roy-Acuff.html
>
> This particular site is especially amazing for its ability to show songs and
> artists from decades far in the future.
> http://www.oldies.com/artist/browse.cfm/decade_2430.html
> http://www.oldies.com/artist/browse.cfm/decade_5350.html
>
> Kind of like Zager and Evans' "In The Year 2525"! (and not in the oldies
> list above)
>
>
> Paul
that site is not even close to mine. They basically give you "bio" of the
various artists. Even though the tab might say "1960", you get a list of
every performer they have a bio on regardless of the decade.
They seem to be more of in the business of selling albums and CD's.
I haven't found a site yet that lists ALL of the songs for a given year in
the sixties.
Top 100 and #1 sites are a dime a dozen.
> | On Fri, 18 Feb 2011 23:15:23 -0500, P E Schoen wrote:
> |
> | > "Jerry Stuckle" wrote in message
> | > news:ijnd59$fci$1(at)news(dot)eternal-september(dot)org...
> | >
> | >> You can't. Such a link is local to the browser; no request is
> | >> made to the server.
> | >
> | >> As others have told you - you need a browser-side solution.
> | >> That is not PHP.
> | >
> | > I would think a server-side database would be most appropriate for this. The
> | > potential amount of information may be several hundred megabytes, while the
> | > information to be presented to the viewer in the browser is only a few
> | > kilobytes, or a bit more if images or sound clips are included. That's why I
> | > had suggested PHP and an SQLite (or MySQL) database on the server.
> | >
> | > Here is a website page that is similar to what richard is doing:
> | > http://www.oldies.com/artist/browse.cfm/decade_1960.html
> | >
> | > It appears that this is organized with a separate web page for each decade
> | > and/or the starting letter of the artist, and finally presented as
> | > individual web pages for each artist. Since the website for just Roy Acuff,
> | > for example, is 2173 lines of HTML with a lot of excess blank lines, I think
> | > these web pages may be generated dynamically, rather than static. Here's
> | > that example:
> | > http://www.oldies.com/artist-view/Roy-Acuff.html
> | >
> | > This particular site is especially amazing for its ability to show songs and
> | > artists from decades far in the future.
> | > http://www.oldies.com/artist/browse.cfm/decade_2430.html
> | > http://www.oldies.com/artist/browse.cfm/decade_5350.html
> | >
> | > Kind of like Zager and Evans' "In The Year 2525"! (and not in the oldies
> | > list above)
> | >
> | >
> | > Paul
> |
> | that site is not even close to mine. They basically give you "bio" of the
> | various artists. Even though the tab might say "1960", you get a list of
> | every performer they have a bio on regardless of the decade.
> | They seem to be more of in the business of selling albums and CD's.
> |
> | I haven't found a site yet that lists ALL of the songs for a given year in
> | the sixties.
> | Top 100 and #1 sites are a dime a dozen.
I think that you might have missed the point :-(
It is not the site(s) themselves but how the information is accessed
and presented.
What you are proposing with your site is very limited in user
usefulness/friendliness.
Having the information within a database will allow flexibility in
accessing and presenting. Also maintenance and expandability of the
information will be a lot easier.
Calendar
Search
Help
Members
Register
Login
Home
]