Injecting code into the <head></head> section

  • Thread starter Thread starter Brian W
  • Start date Start date
B

Brian W

Hi All,

I have a web user control that, among other things, provides Print this
page, and Email this page functionality I have this script that is to
execute on the click of the asp:hyperlinks

I have a function in a <SCRIPT> block that I want in the <head></head>
section of the page. Unfortunately, RegisterClientScriptBlock,
RegisterStartupScript don't always work, and when they do the script is
placed inside the <form> tag (this seems stupid to me).

Is there anyway, from the web user control to insert code into the <head>
section of the page using the web user control?


-- also --

How does one go about debugging java script? Some code I'm working on has an
error and the little "!" icon flashes in the status bar of the browser, then
goes away.


Thanks, as always!

Brian W
 
What reason do you have for wanting to put the script inside the <head>? It
really makes no difference.

HTH,

Kevin Spencer
Microsoft FrontPage MVP
Internet Developer
http://www.takempis.com
Big things are made up of
lots of Little things.
 
To debug javascript, open the page in the latest Netscape. Once the page is
fully loaded, type "javascript:" in the address bar to view the debugger.

Hi All,

I have a web user control that, among other things, provides Print this
page, and Email this page functionality I have this script that is to
execute on the click of the asp:hyperlinks

I have a function in a <SCRIPT> block that I want in the <head></head>
section of the page. Unfortunately, RegisterClientScriptBlock,
RegisterStartupScript don't always work, and when they do the script is
placed inside the <form> tag (this seems stupid to me).

Is there anyway, from the web user control to insert code into the <head>
section of the page using the web user control?


-- also --

How does one go about debugging java script? Some code I'm working on has an
error and the little "!" icon flashes in the status bar of the browser, then
goes away.


Thanks, as always!

Brian W
 
For javascript debugging, make sure you have your IE settings set to enable
debugging and to display a notification about every error. This is in
Option on the Tools menu on the Advanced tab.

I also don't see a specific reason for the script to be in the HEAD section.
Can you please explain what it is you are trying to do, that you think
requires this?
 
if you look in the controls collection, you see the first/second control is
a literal control which contains the <head></head> (if defined on the page).
you can inject your code there with a little string manipulation.

-- bruce (sqlwork.com)
 
To all those that replied, thanks for taking the time to reply...

I have several reasons for wanting to put the script in the HEAD section.

1) A few years ago, at a big e-company, I tried to put some script in BODY
and was chastised for doing so. When I questioned why I was given some
reason about how some errors were processed. And placing the script within
the HEAD section either hid these errors form the end user (sorry for the
vagueness, they made it clear as mud to me then too;).

Is this not true?

2) It seems to be much cleaner. If the implementation of some JavaScript
functions are in the HEAD section then there is only one place to look.

3) All the examples I seem to find have the SCRIPT blocks in the head
section, so I guess It may at least partially be a case of monkey see,
monkey do.... Seriously, if it doesn't matter, then why is it done this way
in so many places?

If I could get RegisterClientScriptBlock and/or RegisterStartupScript to
work consistently then I probably wouldn't care.


Thanks again
Brian W
 
A few years ago it might have made a difference. Today it doesn't. What
problems are you having with the .Net methods?

HTH,

Kevin Spencer
Microsoft FrontPage MVP
Internet Developer
http://www.takempis.com
Big things are made up of
lots of Little things.
 
Kevin Spencer said:
A few years ago it might have made a difference. Today it doesn't. What
problems are you having with the .Net methods?
Click to expand...

Even though, as you say, "A few years ago it might have made a difference".
Aren't those browsers still in use today? And shouldn't one at least try to
support the lowest possible denominator? I know I still see people on some
of the NG's asking questions about Win 95, 98 and their browsers.

As for the problems I have with the 2 methods, I 've been poundin my head
against my desk on that one, and realized the page I was testing doesn't
have a <form> tag. now that I put one in ithey work. but I still have a
problem with that. I may want my code on a page that doesn't have a form
defined. If that's the case then I'm out of luck.

It seems silly to put a FORM on a page that has no need for one.


Brian W
 
Hi Brian,

You asked if those browsers aren't still in use today. Since there are
nearly 7 Billion people in the world, I would have to say "probably yes, a
few." However, you are writing a web application, not a web site with static
pages. And there aren't any professional developers out there that design
for all POSSIBLE browsers. Most developers target version 4 and above of the
popular browsers. Since browsers are free, there are extremely few people
who don't have a version 4 or above. And those people aren't worth worrying
about. Remember, we're not talking about 5-year-old browsers here. We're
talking about 10-year-old browsers.

In fact, if you are going to worry about JavaScript in the <head> of your
page because of older browsers, how do you plan to accomodate those older
browsers that don't support JavaScript at all?

I hope you see my point.

HTH,

Kevin Spencer
Microsoft FrontPage MVP
Internet Developer
http://www.takempis.com
Big things are made up of
lots of Little things.
 
Brian: I tend to agree, that inserting script into the page head should be
an option. The following is from a previous thread. I haven't tried it, but
perhaps it will help:

---- Original Message -----
From: "RadekP" <[email protected]>
Newsgroups: microsoft.public.dotnet.framework.aspnet.buildingcontrols
Sent: Thursday, June 12, 2003 10:34 AM
Subject: Re: Accessing the page head

Chirs

There is certainly a way.

1. Declare the header tag with its "id" and "runat" properties so the page
parser will generate HtmlServerControl after compilation for your header -
to be precise : page parser uses control builders
(System.Web.UI.ControlBuilder or inherited) to build parse tree once it has
parsed the content of *.aspx page comprised of control builder instances
that are converted to a code that are dynamically compiled during a first
request. Anyway simple :

<HEAD id="myHead" runat="server"></HEAD> suffices.

In your code behind you then declare :

protected System.Web.UI.HtmlControls.HtmlContainerControl myHead

And you are free to access myHead properties. You are probably going to be
interested in "InnerHtml" property the most.

2. Place your custom control or any web control that does not make sure to
be rendered inside a form (Page.VerifyRenderingInServerForm)

<HEAD>
<myTag:MyControl id="myControl" runat="server" ContentKey="C#"
ContentName="CODE_LANGUAGE"/>
</HEAD>

Hope that Helps

Regards

Radek

Chris said:
Is there a way to access the page head from the code
behind of an aspx page? I would like to insert a script
block into the page head, and not into the body which is
what the RegisterClientScriptBlock and
RegisterStartupScript seem to do.

It would also be nice to access the page head to insert
the global style sheet reference.
Click to expand...



if the developer wants to put script inside the page head,

Kevin Spencer said:
A few years ago it might have made a difference. Today it doesn't. What
problems are you having with the .Net methods?
Click to expand...

Even though, as you say, "A few years ago it might have made a difference".
Aren't those browsers still in use today? And shouldn't one at least try to
support the lowest possible denominator? I know I still see people on some
of the NG's asking questions about Win 95, 98 and their browsers.

As for the problems I have with the 2 methods, I 've been poundin my head
against my desk on that one, and realized the page I was testing doesn't
have a <form> tag. now that I put one in ithey work. but I still have a
problem with that. I may want my code on a page that doesn't have a form
defined. If that's the case then I'm out of luck.

It seems silly to put a FORM on a page that has no need for one.


Brian W
 
I see your point, Kevin. I wasn't trying to start an argument, really. I'm
just trying to learn the [so called] "right"/best way.

When every example I have seen, in print and on the web, has the scripts in
the <head> section... well, you can see my confusion on the subject when the
previously mentioned methods only place the script within a <form> tag.

BTW I have taken into account those browsers that don't support scripting or
have scripting turned off. My original concern was for those browsers that
supported scripting differently somehow.

Thanks for all your time Kevin.


Regards,
Brian W
 
Back
Top