I'm working on an ASP.Net webforms app, and I've run into a unique issue. There is a script manager for an update panel on the MasterPage, as well as a script manager in a sub-page calling the master page. This as i'm sure you will note cause an exception to be thrown and crash the webapp.
I've tried programatically excluding the scriptmanager + update panel from the code as follows:
<% If Not (Result.RawURL.Contains("ExcludedPageDirectory") Then %>
<!-- all that code goes here -->
<% End If%>
However I think just the presence of the script manager tag in the source is causing the error. How would I programatically handle this?
A page can contain only one ScriptManager control in its hierarchy. To register services and scripts for nested pages, user controls, or components when the parent page already has a ScriptManager control, use the ScriptManagerProxy control (Source: MSDN)
You don't require a script manager again in the page if you have it in the master page.
Remove it and try
I ended up duplicating the master page and left out the update panel/scriptmanager code. This seems to have been the most elegant solution for the given situation. However I feel that the ScriptManagerProxy answer held the best possible solution had the duplication of the masterpage not been possible.
Related
I'm developing an ASP.NET website. Sometimes some modules contain so few content that I present them inside a jQUeryUI dialog and communicate with the server via AJAX. I keep those contents inside a separate file and load them to a jQueryUI dialog according to the appropriate module.I was wondering if it's a good idea to have that content as a plain HTML elements instead of asp ones. Somehow I thought maybe this would reduce the overhead the conversion from asp elements to html elements can cause.
I'd allways go with the aspx Page, because a dynamic Page is more work at the beginning but in the end it almost ever saves time.
Specially when your not sure of the content that will be shown there, it is better.
And for the one reason i do it, is to have everything the same.
One style one way to code.
I'd say this is probably premature optimization. The overhead of an aspx page is in almost all cases negligible. I believe it's more likely that you will some day need to put dynamic things in that page, in which case you would have to convert the html file to an aspx, and change the url for your ajax dialog - which will cost time/money.
If you have aspx pages, or ascs user controls that you do not actually use/run any code, you can set the AutoEventWireup the EnableViewState, and maybe the EnableSessionState to false and stop the calling of the PageLoad and the rest functions and reduce the overhead. So on top of the controls you declare:
<%# Control AutoEventWireup="false" EnableViewState="false" ...
or for page:
<%# Page AutoEventWireup="false" EnableViewState="false" EnableSessionState="false" ...
The disable of the session is let the pages loads in parallel, the disable of the EnableViewState is reduce the size, the AutoEventWireup is reduce the callback hooks and calls.
In general you can use what ever you wish - if your pages can work, but if you like to keep it robust and easy to change or update, or add new functionality in the future, then use dynamic aspx pages.
Similar question: Master page and performance
is it right to put script manager in master page ?
It isn't wrong, as such.
Really depends on your requirements.
If you need to use scripts in several pages that use the same master page, use ScriptManager in the master page.
Just keep in mind that you can only have one ScriptManager in the whole loaded page, so you can't add one in content pages as well.
See this article on MSDN for an example (Using the ASP.NET UpdatePanel Control with Master Pages).
I've found that when using the
<!-- include file="MyPage.aspx" -->
command in ASP, I'm not able to use the code-behind in MyPage.aspx.
The issue is that when I try to include MyPage.aspx, there is an error because we have two Page Directives. If I remove the Page Directive, I can include MyPage.aspx just fine, but cannot access the code-behind, because the "CodeBehind" parameter in the Page Directive is no longer there.
So, as far as I can tell, we have a Catch-22. Does anyone know of a work-around for this? Or is there just something I'm missing?
Thanks,
-Onion-Knight
I'm not sure if this changes anything, but I am using a Master Page with the page that includes MyPage.aspx.
Why don't you use a user control (*.ascx) instead of including an aspx page?
Have a look at this overview in MSDN which shows how to create and user "user controls".
I have a master page that adds the jquery library via a registerclientscriptinclude:
Page.ClientScript.RegisterClientScriptInclude(this.GetType(),
"JQuery",
Page.ResolveUrl("~/Scripts/jquery-1.2.6.min.js"));
In a page that uses that master page I want to include a script that depends on jquery:
Page.ClientScript.RegisterClientScriptInclude(this.GetType(),
"jqplugin1",
Page.ResolveUrl("~/Scripts/jquery.plugin1.compressed.js"));
This causes a problem because the page's client scripts are written first and then the master pages client scripts (causing the plugin to complain that "jquery" is undefined).
Is there anyway to control the ordering of client script includes? Alternatively any recommendation on how best to control this (temporarily the master page is just including everything... but that's not going to work long term).
since master page is like a control embedded in a page, you can add these scripts towards the end of the page cycle, the control would fire first and then page, so your page would be fine.
You could re-include the jQuery library in the page, if it's already there it will simply override it, if not it will be added.
I am looking to make a web control where I can register client startup scripts inline with my aspx because I hate registering in the codebehind!
An example of what I have so far:
<Ben:StartupScript runat="server">
var form = document.getElementById("<% =form1.ClientID %>");
</Ben:StartupScript>
Currently, I am overriding the OnPreRender method of the control, rendering the contents of the control to a string and then manually registering that string as a startup script using ClientScript.RegisterStartupScript on the Page. I also override the Render method in order not to render the control. I should also note that I have the ParseChildren attribute set to false and the PersistChildren attribute set to true.
All seems to be working well, but my control allows other web controls inside it (such as Button). Apart from being unintuitive, this can result in runtime errors. I would love to be able to clear the controls but this is impossible given the <% ... %> code block.
So, is it possible to prevent developers from embedding child controls whilst still allowing code blocks?
Also, is this idea any good or is it fundamentally flawed? Lol.
Thanks a bunch,
Ben
it sounds like a good idea, but if you spend too much time fighting the inherited/default behaviors then it may be more trouble than it's worth
if this is a one-shot issue, a cheap-hack solution is to just directly embed your scripts in the header of a master page ;-)
on the other hand, allowing developers to embed their own scripts as children of your web control might be useful
If you are using master pages, add another control in your section. That way you can easily add css/js to your headers in your child pages.
ClientScript.RegisterScript is mostly for user/server controls,