After searching Google I found one way to call a master page function from a user control:
Create an interface that includes your method.
Implement the interface in your master page
From your control, reference this.Page.Master via the interface type.
Call your method.
This is a good approach, but I don't know that can I call a master page static function in this way.
Another approach is :
// this is also good.
((MyMaster)this.Page.Master).MyFunction();
But I heard that this can also be done through an event.
1) Could someone show me how I could call a master page function from a user control through an event?
2) Also, how can I call a master page static function through a common interface way which I explained above.
I think it'd be better to have your user control raise an event and have your page listen for the event and then call the master page function. Controls shouldn't have any knowledge of the things that implement them - including whether or not the page has a master page.
In your content page, use the MasterType directive to generate the Master type. Then you can use the exposed Master property in the content page without casting. If you want to call a static function in the master from the content, you need to call it using the name of the master's code-behind class (since it is static)
content page:
<%# Page MasterPageFile="~/dir1/master1.master" ....... %>
<%# MasterType VirtualPath="~/dir1/master1.master" %> <!--This technique might change between .net versions. This is testing on 3.5-->
content page.cs
this.Master.nonStaticFunc();
dir1_master1.staticFunc();
Related
I have a user control that I have written and have added to an ASP.NET page, and functions just fine. However, I am trying to reference a property in the that custom control from code behind, on Page_Load, but cannot, because the variable, which is accessible, for the instance is null.
Is this normal for user controls and Page_Load? And if so, how can I make a reference to the control's instance in order to access its public properties? This is something I need to do before the page is rendered, in order to initialize some variables.
I had the same issue, and it turned out that I was registering my custom control incorrectly.
Correct Definition:
<%# Register Src="PeriodControl.ascx" TagName="PeriodControl" TagPrefix="ucs" %>
Incorrect Definition:
<%# Register TagPrefix="ucs" Namespace="MyWebsite" Assembly="MyWebsite" %>
The only difference was to reference the ascx file directly instead of the control in the assembly. Go figure!?
You can probably access your user control from the Page_PreRender event.
You can find more documentation about the page life cycle in asp.net here.
Where's the best place to put a page method so that it's available in every page? The page method is called from the client with a jquery $.ajax{...} function: it sends and receives json objects.
Should I put this page method in a base page or in the master page?
Thanks.
It is more consistent to put such logic in a class that derives from System.Web.UI.Page. Every page that should have that logic should derive from your custom class.
The MasterPage should be used for containing logic relevant to the UI.
Also consider that you may add a page in the future, that should share the same design like the rest of the pages, but not the logic. In that case you would simply derive that page from System.Web.UI.page and use the MasterPage for layout purposes. If you had chosen the MasterPage, you'd either have a page that contains logic it should not, or you'd have to do a rewrite
Do you recommend from every web site created in Visual Studio, that you should create a Base page that serves as the parent class?
What are the exact benefits/drawbacks?
If you want to override the way something in ASP.NET works, it can be more efficient to build it into a base class rather than including the code in every page. Two specific instances where I've done this are:
IsPostback
Little-known fact: it's quite feasible to craft a request that, to ASP.NET, looks like a postback but is submitted with a GET request. Who does this? Hackers, that's who. A call to IsPostback in this case will return true, but it shoud really return false. To get round this, build a base class that overrides IsPostBack:
Public Class MyBase
Inherits System.Web.UI.Page
<DebuggerStepThrough()> _
Public Shadows Function IsPostback() As Boolean
'Check the built-in IsPostback and make sure this is a HTTP POST
Return (Page.IsPostBack AndAlso Request.HttpMethod.ToUpper = "POST")
End Function
End Class
Error Handling
In Beginning ASP.NET Security, Blowdart talks about the fact that if you use ASP.NET's error handling to redirect the client to a custom error page, hackers (again) can detect the redirection and flag it as an error that may be exploitable. A more secure pattern is to handle the Page's Error event and do a Server.Transfer (which doesn't send anything to the client). Again, doing this in a base class means you only write the code once:
public partial MyBase : System.Web.UI.Page
{
protected void Page_Error (object sender, EventArgs e)
{
Exception ex = Server.GetLastError();
// Do something with the exception e.g. log it
...
Server.Transfer("~/mycustomerrorpage.aspx");
}
}
Yes, I do.
But please remember that the purpose of a base page is totally different from the purpose of a master page.
Let me explain.
Master pages
are layout elements used to share the same graphical features and part of the webforms behaviour (think a login/logout box with code-behind) across all pages that are associated to the master. Your final page classes will include a reference to the master page so the final result will appear as the master page including your page (check the source code to tell who contains whom)
Base pages
are (abstract? at least not sealed!) classes from which all your pages inherit from the code-behind view. Unless you explicitly and programmatically add controls to the basae page, ie. in the constructor via LoadControl method, all pages will look blank from the very beginning until you add code.
But often they are useful. If you want to override some of the base class methods, you can have the overriden behaviour shared across all pages. Or, you may want to expose application-specific objects to the children pages (a reference to a data access layer, a logger or whatever). An example is overriding UICulture property to retrieve the user-preferred language from cookies.
Both can be combined
Depending on your goals, you may combine master pages with base pages.
I suggest you to always create a base page class, since if your application's requirements change over time and you already created lots of pages, you can try to modify the base class to have the modifications propagated to all pages, according to the level of complexity of them.
Check out masterpages this is their primary purpose.
Here's a link: http://msdn.microsoft.com/en-us/library/wtxbf3hh.aspx
This will serve as the template for your site. You would add a content section that would make up the body of your site. You can reference the master page is your subpages to have a consistent layout, menu, etc. for you site.
Also, like the others have noted. If you are running any commond code, just create a class a reference it from wherever you need it.
It depends on the size and complexity of your project. For small websites with minimal functionality, a base page might be overkill. That said, I would typically use it for site-wide functionality, such as security. I tend to keep functionality in the master pages to a minimum since their primary purpose is to organize your layout and factor out common display areas from you content pages to avoid duplication and ease maintenance.
To create a base page for use in a master page scenario, you could use the following syntax:
Master Page:
<%# Master Language="C#" AutoEventWireup="true" CodeBehind="MyProject.master.cs"
Inherits="MyProject.MasterPages.MyProject" %>
<asp:ContentPlaceHolder ID="ContentPlaceHolder1" runat="server">
</asp:ContentPlaceHolder>
Base Page:
<%# Page Title="" Language="C#" MasterPageFile="~/MasterPages/MyProject.Master"
AutoEventWireup="true" CodeBehind="BasePage.aspx.cs"
Inherits="MyProject.BasePage" %>
<asp:Content ID="Content2" ContentPlaceHolderID="ContentPlaceHolder1"
runat="server">
</asp:Content>
Content Page:
<%# Page Title="MyProject - Home" Language="C#"
MasterPageFile="~/MasterPages/MyProject.Master" AutoEventWireup="true"
CodeFileBaseClass="MyProject.BasePage" CodeFile="Default.aspx.cs"
Inherits="MyProject.Default"
Meta_Description="Code Snippet: Master Page and Base Page"
Meta_Keywords="master, base, content" Theme="Style" %>
<asp:Content ID="Content2" ContentPlaceHolderID="ContentPlaceHolder1"
runat="server">
</asp:Content>
If you need common functionality on all your pages that belongs to the page class, create a common base class.
If you don't need such common functionality on all your pages, don't create a common base class.
If you can't decide, having a base class isn't going to hurt anybody, so you might as well have one (I'd say you more often end up needing some common functionality than not)
I have a Master Page which controls the styling of my site. In the Code Behind, there are a few class instances instantiated as well as variables. These classes validate user access and then create user objects
I have a few Web Content Forms which carries out instructions based on the user objects. So far it seems that on each Web Content Form I have to create new instances of the classes found on the Master Page. This is doubling my work for every Web Content Form.
Is there anyway I can inhereit Classes and objects instantiated in the Master Page Code Behind?
Expose the objects (and even controls) as public properties (get only for controls) on the Master page. Then, in each aspx page you want access to these objects, add the following declaration at the top:
<%# MasterType VirtualPath="~/MyMasterPage.master" %>
As #Kristof points out, simply access your properties like Master.PropertyName
Also, you can determine if it makes sense to store the objects in the users Session (don't forget that they must be serializable if you use DB for session state). I do this often and control access to them via properties in a base Page class that all my pages inherit from. Actually, I have a base master, page, and usercontrol so I have access to the same properties (for me it's CurrentUser) everywhere.
I believe you can if you make the properties public.
Then in your child-page you can make the call something like this:
SiteMaster master = (SiteMaster)this.Master;
master.MyProperty = 0;
Where SiteMaster is the class for your master page. (SiteMaster is the default for the app templates)
Though my mind can deceive me, I haven't done it for a while...
I have a page with the following caching defined:
<%# OutputCache Duration="60" VaryByParam="None" %>
I have a user control inside that page that i don't want cached. How can I turn it off just for that control?
Option One
Use the Substitution control or API on your page. this enables you to cache everything on your page except the part contained within the substitution control.
http://msdn.microsoft.com/en-us/library/ms227429.aspx
One nice way to use this is to implement your control as a simple server control which renders the html as a string, but does so in the context of the page (that is with the correct Client IDs). Scott Guthrie has a really nice example of how this works. Works nicely with AJAX calls too by the way...
http://weblogs.asp.net/scottgu/archive/2006/10/22/Tip_2F00_Trick_3A00_-Cool-UI-Templating-Technique-to-use-with-ASP.NET-AJAX-for-non_2D00_UpdatePanel-scenarios.aspx
Excerpt from Scott Gu's article...
[WebMethod]
public string GetCustomersByCountry(string country)
{
CustomerCollection customers = DataContext.GetCustomersByCountry(country);
if (customers.Count > 0)
//RenderView returns the rendered HTML in the context of the callback
return ViewManager.RenderView("customers.ascx", customers);
else
return ViewManager.RenderView("nocustomersfound.ascx");
}
Option Two
Render the dynamic control via an AJAX call on the page load. This way, you can safely cache the entire page (including the AJAX call) and it is only the rendered result of the call that changes between pages.