I have a page test.aspx which is inheriting master page.The master page has script manager addeded to it.I am trying to add the rating control availabel in the ajax control toolkit.
So i need to add the line <Ajax:ToolkitScriptManager ID="ToolkitScriptManager1" runat="server"/>
But since the script manager is already availabel in master page i cannot add this line to my test page.And if i dont add it will not function.
What should i do?
Is there difference between script manager and toolkitscriptmanager.
How to use both simultaneously?
You can replace the scriptManager in the master page with <Ajax:ToolkitScriptManager ID="ToolkitScriptManager1" runat="server"/> .This will certainly solve your problem.
First of all: if you use ASP.NET 3.5 and controls from AJAX Control Tookit then you must use the ToolkitScriptManager, rather than the ASP.NET ScriptManager. This limitation according to the fact that toolkit script manager adds updated Ajax scripts and without that most of the controls from Ajax Control toolkit library will not work.
If you using ASP.NET 4.0 (4.5) than you have choice to use ScriptManager or ToolkitScriptManager.
Basically the main feature of the ToolkitScriptManager is that it can combine js resource added to page using ScriptReference collection. These js files should be embedded to assembly and for this Assembly ScriptCombine assembly attribute should be added. The main problem here is that you can't control how scripts are combined and after you will try to combine your own scripts you can have a lot of problems (I had experience using this feature and as a result we rejected combining of our scripts using this approach).
The main point here is that currently standard script manager has ability to combine scripts using composite script collection.
Related
Any suggestions on the following error:
"Could not find any resources appropriate for the specified culture or the
neutral culture. Make sure "AjaxControlToolkit.Properties.Resources.NET4.resources"
was correctly embedded or linked into assembly "AjaxControlToolkit" at compile time,
or that all the satellite assemblies required are loadable and fully signed."
I added ajax control toolkit to my project....
Make sure you have: ScriptManager on your .aspx page.
Note: There is one special requirement when using the controls from the AJAX Control Toolkit. The page must contain a ScriptManager control. The ScriptManager control is responsible for including all of the necessary JavaScript required by the AJAX Control Toolkit controls.
<asp:ScriptManager ID="ScriptManager1" runat="server">
</asp:ScriptManager>
I have developed an ASP.NET chat application. Now I want some integration with my Tridion page. To do so I need some code behind file for the published page. And one more issue suppose I want to add a button in my page with its click event. How can I achieve that?
what I've done :
<%# Page language="c#" Inherits="SDLchat.ChatWin" CodeFile="ChatWin.aspx.cs" %>
<%# Register src="ChatLogin.ascx" TagName="c2" TagPrefix="uc2" %>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" >
<HTML>
<HEAD>
<title>ChatWin</title>
</HEAD>
<body>
<form id="Form1" method="post" runat="server">
<asp:Panel ID="Panel1" runat="server">
<uc2:c2 ID="log2" runat="server" />
</asp:Panel>
<asp:Panel ID="Panel2" runat="server" Visible="False">
<asp:LinkButton ID="LinkButton1" runat="server"
onclick="LinkButton1_Click">Change Room</asp:LinkButton>
</asp:Panel>
</form>
</body>
</HTML>
This is my ASP.NET web app that I want to migrate in Tridion. Please help
So you have two files for every page in this application:
the ASPX file that contains the markup
the CS file that contains the code
Since Tridion publishing is based on one-file-per-page, you can get both of these files published from Tridion by creating two separate pages for them. Alternatively you can choose to just publish the ASPX from Tridion and deploy the CS file when you deploy the web application to IIS.
I'd suggest putting the ASPX contents into a DWT Template Building Block in Tridion and then using that one as the only Building Block in a Compound Page Template.
If you decide to also publish the code-behind CS file from Tridion, create a separate DWT for it, paste the code in there and create a separate Compound Page Template for it.
On your second question about a PageLoad event: Tridion will just publish the files that you put in it in this case. It has nothing to do with the ASP.NET code you put in those files. If the ASP.NET page-load event works outside of Tridion, it'll work when you publish the same files from Tridion.
Frank has made an accurate answer, but I would consider it a very bad practice to publish any code from the CMS to the Web Application. Using that approach makes it impossible to test your entire application as CMS users can incrementally update the application.
I would strongly suggest putting all your code behinds into the web application and deploying those through your typical web application deployment process offered by tools such as Visual Studio, and only publishing the ASPX files which have references to the code which is already in your web application.
I agree with Chris here, just because it is possible to publish just about anything from SDL Tridion CMS (including dlls, .config files, uncompiled code etc. etc.) doesn't mean you should.
The lifecycle of application logic (or code) is very different to the Content life cycle. Typically code changes need to be carefully deployed, tested, fixed and redeployed throughout dev, test, acceptance environments before being deployed on production by technical users in a single action. Depending on your organization you may have monthly or shorter/longer development and deployment cycles.
On the other hand, your real life content typically lives the production environment only and is updated as often as required (perhaps hourly or even more frequently) by non-technical users.
If you confuse Content Management with Application deployment you will quickly get into a mess. Imagine someone accidentally unpublishing the App_Code structure group? What if an editor republishes an entire Structure Group but didnt realize that you were halfway through making some changes to the code behind? How are you going to ensure that the dll in the bin structure group gets published at exactly the same time as the web.config and the ascx controls registered in it which are somewhere else? Best case your application might not work, worst case you get compilation errors throughout your entire site.
Some guidelines that I have seen and used on various ASP.NET/SDL Tridion sites are as follows:
Use a standard base page (or limited set of base pages, perhaps determined by page template) as a common code behind for all your published aspx pages - put generic logic in here
For any specific functionality, encapsulate this in a control (ascx or web control) and put logic in the code for this
Have the .cs for the base page, code behind for controls and other logic in a compiled dll in the bin directory - App_Code is great for development, but can create deployment headaches with all those different files to manage
i am using jquery and jquery ui plugins in my web application.
and i have some asp.net server controls that they register their scripts on the page.
Since my application should be work Local could i put all scripts in master page ?
all scripts i mean jquery script and jquery Ui scripts such as DatePicker Dialog and effects.
or is there any better way exist?
because i want to jquery in all my pages and user Controls.
thanks.
Sticking them in the master is definitely the simplest approach if you intend to have them available on every page.
It sounds like you're including all the scripts individually though, you can include just one file for jQuery UI, for instance:
<script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jqueryui/1.8.5/jquery-ui.min.js"></script>
Yes, put them all in the Master Page.
Once they're downloaded, they'll be cached in the browser (if they already aren't)
Hello: we currently do not use asp.net controls (no web forms). The way we do is:
1> Read HTML file from disk
2> lookup database, parse tags and populate data
finally,
Response.Write(page.ToString());
here there is no possibility of using asp.net controls. What I am wondering is, if we use asp.net controls in those HTML files, is there way to process them during step 2?
Thanks and appreciate your response.
I haven't tried this but you might want to attach the html extension to the ASPNET ISAPI filter in your IIS and in your page, step 2, use Server.Execute and call out that html file. However that page will execute on its own.
If these html pages from step 1 are meant for making up parts of the page that needs to get inserted in parts of the webform (.aspx), I suggest that you make use of master pages instead.
If the html pages are standalone pages that need extra functionality you can simply upgrade them to webforms without codebehind if needed. Custom made macros in Visual Studio can help a great deal in this transition effort.
I have an aspx page that get copied in the layouts directory of a Project Server instalation. The aspx is a web part page that has a web part zone. How can I add a web part in the markup of the page, within the web part zone?
You can use the SPLimitedWebPart manager to add an instance of a web part at runtime. I do this on our MySites to control adding, deleting and moving web parts that the organization requires. You can put the code in the aspx page.
SPFile thePage = currentWeb.RootFolder.Files["default.aspx"]
using (Microsoft.SharePoint.WebPartPages.SPLimitedWebPartManager spLimitedWPManager = thePage.GetLimitedWebPartManager(System.Web.UI.WebControls.WebParts.PersonalizationScope.Shared))
{
Assembly assembly = Assembly.Load("WebPartAssemblyName");
WebPart webPart = (WebPart)assembly.CreateInstance("WebPartClassName");
spLimitedWPManager.AddWebPart(webPart, ZoneId, ZoneIndex);
}
You may need to do something different to gain access to the Web Part Manager for your layouts page. After this you need to redirect back to the page to display the changes. You'll also want to store a bit value to ensure that you do not perform the action on each subsequent visit.
If you only need to do this once then I might recommend PowerShell instead.
Otherwise you can add the web part directly in MarkUp by registering the tag:
<%# Register TagPrefix="ABC" Namespace="Namespace" Assembly="Assembly" %>
and directly adding the web part,
<ABC:ClassName ID="ControlID" FrameType="None" runat="server" __WebPartId="YouWebPartGUID" WebPart="true" />
but we didn't do it inside of a web zone because we did not want to allow it to be removed so I do not know if it works in that scenario. This is easiest but doesn't allow for any customization and SharePoint doesn't really "know" about the web part.
You cannot have customizable Web Part pages in the layouts directory! This is only supported on Web Part pages stored in a document library or other folder in an SPWeb, i.e. ASPX files that you can get an SPFile reference to. Web Parts on ASPX pages in the layouts directory must be added as Web controls in the ASPX source.