Hi All,

Let's say we have site index.html with JS embedded there in this
way:

<script type="text/javascript" src="my_script.js?username=mr_bean"></
script>

Question:
How to get access to "username" query string constant directly from
my_script.js file ? "location.search" is no option here because it
will access index.html's QUERY STRING not my_script.js's. Any idea ?

Best regards,
Marcin Zduniak

Le 9/24/08 5:15 PM, Marcin a écrit :
> Hi All,
>
> Let's say we have site index.html with JS embedded there in this
> way:
>
> <script type="text/javascript" src="my_script.js?username=mr_bean"></
> script>

funny idea, no ?

> Question:
> How to get access to "username" query string constant directly from
> my_script.js file ? "location.search" is no option here because it
> will access index.html's QUERY STRING not my_script.js's. Any idea ?

var S = document.getElementsByTagName('script');
for(var i=0, n=S.length; i<n; i++)
if(S[i].src.toString().indexOf('my_script') >=0) {
alert('var = '+S[i].src.toString().split('=')[1]);
break;
}


--
sm

Marcin wrote:
> Let's say we have site index.html with JS embedded there in this
> way:
>
> <script type="text/javascript" src="my_script.js?username=mr_bean"></
> script>
>
> Question
> How to get access to "username" query string constant directly from
> my_script.js file ? "location.search" is no option here because it
> will access index.html's QUERY STRING not my_script.js's. Any idea ?

The script cannot "know" how it is included. However, you can use a
server-side script to generate a client-side one, and the former can
read the query part of the request URI.

For example, in my_script.js.php (I would use Content Negotiation to get
rid of the security-relevant `.php' in the URI):

var username = "<?php echo addslashes($_REQUEST['username']); ?>";


PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7@news.demon.co.uk>

On 2008-09-26 20:24, Thomas 'PointedEars' Lahn wrote:
> For example, in my_script.js.php (I would use Content Negotiation to get
> rid of the security-relevant `.php' in the URI):

I wouldn't. I suppose content negotiation could also be (mis)used to
hide an extension, but it was really intended to serve alternate
representations of resources depending on the UA's capabilities and
preferences (different languages or media types). See RFC 2616.
URL rewriting would be more appropriate to hide or change file names.

- Conrad

Conrad Lender wrote:
> On 2008-09-26 20:24, Thomas 'PointedEars' Lahn wrote:
>> For example, in my_script.js.php (I would use Content Negotiation to get
>> rid of the security-relevant `.php' in the URI):
>
> I wouldn't. I suppose content negotiation could also be (mis)used to
> hide an extension, but it was really intended to serve alternate
> representations of resources depending on the UA's capabilities and
> preferences (different languages or media types). See RFC 2616.
> URL rewriting would be more appropriate to hide or change file names.

URL rewriting cannot be reasonably applied to this problem: you would have
to write expressions for each script file (and have PHP parse all, which is
inefficient), or write an expression for all directories where you have to
keep all your generated script files (which is inflexible).

I might add that He who invented the Web and those who largely implemented
it disagree with you about the use of content negotiation as I do:

<http://www.w3.org/Provider/Style/URI>
<http://httpd.apache.org/docs/2.0/content-negotiation.html#naming>


PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7@news.demon.co.uk>

On 2008-09-26 21:49, Thomas 'PointedEars' Lahn wrote:
> URL rewriting cannot be reasonably applied to this problem: you would have
> to write expressions for each script file (and have PHP parse all, which is
> inefficient), or write an expression for all directories where you have to
> keep all your generated script files (which is inflexible).

How many script files do you want to generate for each request? In
practically all of the projects that I've worked on, there was no need
to have more than one external JavaScript file (if any) that contained
dynamic information. That one script would usually be very short and
only contain a few custom settings that were used as "constants" by the
rest of the (static and cacheable) script files. More likely, these
definitions would not go into an external script file at all, but would
be added inline in the <head> of the HTML page (saving one request).

There may be situations where modules in a framework each want to add
their own dynamic script file. But in this case, there is usually a
single point of entry anyway (an /index.php file, for example) which
would take care of generating any dynamic content based on the PATH_INFO
env, without any need for content negotiation or URL rewriting.

> I might add that He who invented the Web and those who largely implemented
> it disagree with you about the use of content negotiation as I do:
>
> <http://www.w3.org/Provider/Style/URI>
> <http://httpd.apache.org/docs/2.0/content-negotiation.html#naming>

But they do not disagree. In fact, they don't compare URL rewriting and
content negotiation at all. The first reference is indeed interesting
(written by Sir Tim, no less), but *very* old. The introduction states:

| This document was written in the early days of the web (1992),
| defining such terms as "webmaster", the "www.xxx.com" convention, and
| a few basic points which are just as valid today. It has not been
| updated to discuss recent developments in HTML., and is out of date in
| many places, except for the addition of a few new pages, with given
| dates.
....
| Some of the points made may be influenced by personal preference, and
| some may be common sense, but a collection of points has been
| demanded, and so here it is.

Rewrite engines have been around for quite a while now, and there's
hardly a major project where URL rewriting of some sort isn't heavily
used. Sure, it may be a little trickier to set up than content
negotiation, but it's well worth learning.

I'm not sure why you included the second link, since it explicitly
states that content negotiation is intended to let the server "choose
the best representation of a resource based on the browser-supplied
preferences for media type, languages, character set and encoding." The
examples in the fragment you linked to are language and gzip compression
- both prime examples of switching by UA preferences and capabilities.

Anyway, the point is moot. It seems like all of our discussions tend to
end in YMMV anyway (I guess Perl doesn't have a monopoly on more than
one way of doing things ;-). I usually go with the solution that was
designed for a certain problem or situation; other solutions may work as
well, but in this case it feels like a bit of a hack.


- Conrad