Tridion ASCX DCP does not render child control - tridion

When publishing dynamic component presentations using SDL Tridion 2011 SP1, I mostly use REL as the output format, however I now want to publish a DCP that contains an ASP.NET control tag. I therefore changed the output format of the template to ASCX, and configured the storage for ASCX component presentations to go to the file system within my web application. I can see the ascx files on disk, and as expected, I can see the control tag inside.
If I create an aspx page that contains the same control tag, the output is as I expect, however, when the ASCX component presentation is executed by the component presentation assembler, instead of rendering the output from the control tag, it comes up blank. Plain text within the DCP does show up.
The functionality I need is very similar to a Tridion Dynamic Component link control, and I had already tried one of these with this architecture, and succeeded. I've even gone as far as putting both my tag and the tridion one, one after the other, in the template. In this case I see the output from the tridion tag, but not from my own, even though the references are wired up in the same web.config.
So I can see that it is possible to have Tridion's component presentation assembler execute an ASCX DCP and successfully render its child controls. Are there perhaps requirements when authoring such a control to ensure that it can be rendered in this way?
UPDATE:
The DCP is published to an ascx file within my site. For test purposes, I am now publishing the tridion control in the same DCP, so the output on disk looks like this:
<tridion:DynamicComponentLink PageURI="tcm:34-667-64" ComponentURI="tcm:34-876"
TemplateURI="tcm:34-864-32" LinkText="Some page" runat="server" />
<xxx:ComponentLinkQS runat="server" ComponentUri="tcm:34-945"
QueryString="item=876" Text="Some page" />
When the DCP is published like this, and executed by the ComponentPresentationAssembler the first control produces the expected output, and the second one doesn't. If I place a <xxx:ComponentLinkQS/> tag directly on an ASPX page, it renders fine.

I think that I've seen this before (full credit for the solution goes to Neil Gibbons and Hoang Chu).
The problem is caused by the ComponentPresentation server control inside the Tridion.ContentDelivery DLL and in particular the way this control loads in the DCP user control during it's Render method:
protected override void Render(HtmlTextWriter writer)
{
if (HttpContext.Current != null && HttpContext.Current.Application != null)
{
ComponentPresentationAssembler componentPresentationAssembler = new ComponentPresentationAssembler(this.pageUri, base.Page);
writer.Write(componentPresentationAssembler.GetContent(this.componentUri, this.templateUri));
base.RenderChildren(writer);
}
}
The Render method is too late in the control life-cycle for any other controls to have their events wired up - hence my user controls Page_load is never triggered.
There is a solution proposed for this on the Tridion forums on the link below which involves overriding the standard Content Delivery user controls to execute your embedded controls earlier in the life cycle: https://forum.tridion.com/topic.asp?TOPIC_ID=5709&whichpage=3&SearchTerms=Page_Load
(I am not sure about the legalities of copying code from the forums and adding it here. If someone from Tridion gives me the nod then I can add it in.)

Related

Master page oddity on server deployment

I have inherited a solution created in ASP.net with VB.net and am having a real problem with the error message "Content controls have to be top-level controls in a content page or a nested master page that references a master page."
The design is somewhat complex as follows:
The app uses a single Masterpage. The child page accessed has a custom user control on it. The user control contains, amongst other controls, an iframe. The source of the iframe is set programatically to another page, (aspx) which does not inherit from the Masterpage as we don't want the headers, footers etc. to appear in the iframe.
This aspx page has another custom user control on it that displays a small number of controls, buttons, text fields, file upload etc.)
This all works well in my IDE (Visual Studio 2005) and the file upload control is displayed properly. As soon as it's deployed to a server, (test or live) I get the error message at the beginning of this post.
The pages and code are too complex to post here but if I haven't given enough detail I will try to explain as necessary. I hope someone can help as this has been driving me insane. I've searched extensively with no success.
Many thanks.

How are custom controls instantiated in asp.net?

My understanding is that when a component or custom control is defined in an aspx page using the <%Register%> tag, it is declared in an auto-generated designer.cs (C#) file by the compiler. If this custom control is never used in the aspx page, does this still happen in the designer.cs file?
Assuming the control is used in the aspx page, what mechanism then instantiates this control, how is it new-ed up behind the scenes? The designer file only declares it. Thanks much, and if there are good articles out there discussing this I’d be happy to read them.
This may not answer all your questions, but some of them. Rick Strahl wrote a great article a while back on compilation and deployment that describes how it works:
Compilation and Deployment in ASP.NET 2.0
I added part of the article that I think relates most to your question below:
Referencing other Pages and Controls
Remember that page and control compilation happens on a per directory basis! So referencing other pages and controls becomes a little more tricky for ASP.NET 2.0, because you can no longer assume that a CodeBeside class from another page or control is available in the current assembly. At best all pages and controls in the same directory end up in the same assembly, at worst each page or control gets its own assembly and they know nothing about each other.
If you need to reference another page from a control or another page you need to explicitly import it with the #Reference directive. Again this is different than ASP.NET 1.1 where all CodeBehind classes were immediately available to your entire Web application. In ASP.NET 2.0 an explicit assembly reference is required to load it.
Assume for a minute that you have the DataEntry.aspx page I showed earlier and you want to create a second page that uses the same CodeBeside class so you can reuse the page logic, but change the page layout in DataEntry2.aspx by changing a few colors and moving around the controls of the page. In essence you want to have two ASPX pages reference the same CodeBeside file.
Here’s how to do this:
<%# Reference Page="~/DataEntry.aspx" %>
<%# Page Language="C#" AutoEventWireup="true" Inherits="DataEntry" %>
I’m leaving out the CodeFile attribute reference the CodeBeside class of the DataEntry page, and add the #Reference tag to the page to force the CodeBeside class to be imported.
The same is true with any User Control definitions. To import a user control you need to use the #Register tag, which imports the assembly that the control lives in. ASP.NET is smart during compilation and figures out exactly where related assemblies live based on how the project is compiled. If the control or page lives in the same assembly no reference is actually added. But if it is external – in another directory for example, then the assembly reference is added.
Referencing problems
If you can explicitly reference other pages and controls in your markup pages, then all works well and as expected. But if you dynamically load controls or reference pages dynamically in your code, things get a lot more complicated.
The most common problem I run into is dynamic loading of controls. In ASP.NET 1.x you might have run code like this for dynamically loading controls into a page:
public partial class DynamicControlLoading : System.Web.UI.Page
{
protected CustomUserControl MessageDisplay = null;
protected void Page_Load(object sender, EventArgs e)
{
MessageDisplay = this.LoadControl( "~/UserControls/CustomUserControl.ascx") as CustomUserControl;
this.Controls.Add(MessageDisplay);
}
protected void btnSay_Click(object sender, EventArgs e)
{
this.MessageDisplay.ShowMessage(this.txtMessage.Text);
}
}
CustomUserControl in this case is a simple User Control that lives in another directory and is loaded dynamically at runtime. Further assume that you truly dynamically want to load this control so you may have a choice of several controls, or the end-user might even create a custom control that gets dropped into place instead.
If you run the code above in ASP.NET 2.0 it will likely fail. I say likely because there are some inconsistencies that will sometimes pick up control references automatically, for example if the user control lives in the same directory and gets compiled into the same assembly as the page, or if another page has the control referenced.
It should and usually will fail. Why? Because ASP.NET compiles on a directory level and the CustomUserControl lives in a separate directory and so goes into a separate assembly. It’s not visible to page class to get a strongly typed reference. Intellisense will show a big, fat and red exclamation point or nothing at all for the MessageDisplay control. When you run the page it will bomb.
You can reference the control as the Control type of course, but if you need to access any custom properties on the user control beyond Control properties you can’t unless you resort to Reflection. As far as I know there’s no way to add a reference to another user control or page programmatically because the reference needs to be available way earlier at compile time before your code ever runs.
Alternatives are to not load controls dynamically or at least provide some mechanism to load up any user controls beforehand on a page with the appropriate #Register tags. But that’s not always possible. The other option is to create a user control base class in APP_CODE and expose the public interface there. The main problem with this is that this base class will not have access to any internal controls of the user control and so the base class would have to use FindControl to reference any embedded controls. So this is inefficient as hell, and cumbersome to boot.
I’ve run into similar situations with inheritance scenarios. For example, inheriting one master page off another’s CodeBeside class. All works well, but the ASP.NET compiler complains that the Profile object is being overridden illegally (a compiler warning). Running with the inherited master page works, but there are quirks. User Controls added to the master page often fail with type conflicts as ASP.NET treats the user control added to the base page as a different type than the user control added to the second page.
It’s inconsistencies like these that deal with referencing other types that have made me waste an incredible amount of time, thinking I had something fixed only to find out later that it didn’t actually work consistently when I changed a completely different page. Worse you have to really understand the model to get your head around what might be wrong.
Bottom line: The overall ASP.NET 2.0 compilation model is internally complex. Most of the time you don’t need to understand it, but when you run into these boundary scenarios, you really DO have to understand what goes on behind the scenes to be able to work around the quirks.

Why don't my user controls render?

I've created a set of user controls in vb.net and in their original project they work fine.
I've since created a user control library dll and I wish to use it in a new project.
I add the reference to the dll fine, specify the tag library in an asp.net page fine and define controls on the page fine.
Everything seems to work except I get no rendered output.
Various properies of the controls and the page_load methods are all called.
Asp.net trace shows the controls in the page hierarchy etc
Just no output where the controls should be - any suggestions?
Update 1
I just compared a trace of the working output compared to the non working.
The working output contains the user controls (and all elements in them)
The non working output only lists the user controls - no content
It therefore seems that the content of the controls is missing somehow - as if the markup is not being compiled with the codebehind, only the codebehind seems to be working.
Update 2
The controls are inheriting from UserControl not control.
You are correct in your summarization in Update 1- your markup has not been included!
You need to provide a bit of elbow grease if your trying to distribute .ascx controls in a .dll but not too much thankfully.
The two main things you need to do:
Embedded your .ascx controls. The .ascx controls need to be marked as an embedded resource in your .dll (as oppossed to 'content')
Create a VirtualPathProvider. This will allow you to load the ascx files directly from the dll they are embedded in.
Unfortunately explaining step 2 is slightly lengthy, however this excellent article helped me out in doing exactly what you want to do.
The beauty of distributing .ascx controls like this is that you dont have to tear your hair out writing custom controls (rendering anything over than very simple html is a nightmare to make sense of).
I assume that you are not confusing between user control (.ascx) and custom controls. For user controls to work, one needs both ascx (mark-up file) along with corresponding code-behind class. User control are typically consists of constituent child controls whose hierarchy is specified within ascx file that provides some UI. In a class library (dll) project, you cannot package ascx files - all you get is the code-behind class. Without ascx, the code-behind class will not have any child controls and hence will render empty. In short, you cannot package user controls (ascx) in a class library - you have to add them into your actual web project.
For shared control, one has to use custom controls. Custom controls are code-only and typically provides render override that emits necessary html (or creates the own child control tree dynamically). These controls can be package as a class library and shared across project. Typically, a custom control will also have other helper classes to provide design time assistance (UI Editors etc).

Add a usercontrol as the value of a html attribute

I am working in a CMS where we use tokens ( which is turned into a user control. Is there a way to add the user control into an attribute value for our template style?
example :
<div class="<$tokenName/$>" />
this currently outputs an encoded user control, which is then not parsed by IIS.
Short answer: this is not possible.
Longer answer...
It's not IIS's job to parse the control... that happens when IIS hands off the request to the ASP.NET engine. ASP.NET does a single-pass parse through your ASPX before the Page lifecycle even starts... this is why controls you delcare in the ASPX are available during the Init event. Whenever your CMS expands "$tokenName", you are far past the point at which ASP.NET is interpreting your markup.
If you're having trouble with that, here's a thought experiment for you: What happens when $token expands into a user control that has some other $token2 control embedded in it? And that control contains some other $token3? How many times are you going to try and parse/expand/interpret your markup?

Why is my web control null?

I have a web site in asp.net that uses a master page. In this master page I have a multiview control with one view that has all the content for the content pages and one view that has some local content to the master page where I show error messages from all content pages.
In this error view I have a asp.net Label control that displays the error messages. Usually the label works fine, but in some few cases the label is null, which renders a NullReferenceException. Now I have handled this case by checking if the label is null before using it, but still my question is:
Why is this label null? What are the circumstances that can generate this?
EDIT: In the master page I have a method called SetErrorText that takes a string and sets the label. I'm calling this method from the content pages' Page_Load method, and this generally works fine. In all but two cases (that I've discovered so far) the label is initialised, and nothing separates these two cases from all the ones that work.
Also, all other controls in the master page are initialised, such as the View-control that houses the label.
When the Page_Load of a content page rolls around, the master page should be populated.
It seems that the problem was one of sloppiness. Someone had forgotten to delete the auto-generated Content-controls that Visual Studio throws in on all content pages where the master page has a ContentPlaceHolder-control.
If a content page has a Content-control, all controls that are placed in the ContentPlaceHolder-control on the master page will be null, it seems.
What method on the master page are you accessing the label from? Depending on the stage of the page lifecycle, the label control may not have been loaded yet
Could you be accessing it before it is created? Check the page lifecycle: http://msdn.microsoft.com/en-us/library/ms178472.aspx
I had a very similar error. In my case it was caused by .NET compiler wierdness related to the control designer file. Even if the designer file has the controls defined correctly, delete it, re-generate it and rebuild (make sure to rebuild, don't just 'build'). See the top answer here for how to do regenerate the designer file:
How do you force Visual Studio to regenerate the .designer files for aspx/ascx files?

Resources