Here's a code that I have in two different web applications:
<ig:WebPercentEditor MaxValue="100" ID="InterchangePlus"
runat="server" ValueText="0" MinDecimalPlaces="2" Width="85px">
</ig:WebPercentEditor>
They both save the data to the same place and retrieve it from the same place. The control in one web application shows the information as 1.75%, the other shows it as 175.00%. Again, the same markup is used in both web applications.
It seems that there was a theme being applied in the web.config setting the DisplayFactor="1" in one web app but the asp.net theme was not present in the other web app
Related
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 have a schema "control" having a field named "tag" (text type) . Now I have created a component with this schema and fill the "tag" field as :
<RegForm:MyRegisteration runat="server" />
and updated web config file.
<add src="~/WebUserControl.ascx" tagName="MyRegisteration" tagPrefix="RegForm" />
I have added the Component to the Page.
Now I want to know is this the way to render the controls or any other better approach to do so.
As I mentioned in some other posts, Tridion doesn't really care about what you're outputting. If your template writes the code that your ASP.NET or Java application needs to run, then it will run.
I wonder if you need to have this has a component, do you expect editors to create the control as part of their content? Do you need to translate it?
Normally this type of "content" goes in the template, not in the components.
The important thing to keep in mind is always: what will be written to the application server?
I have used the "Code Component" approach for publishing .net pages on a client site that did not have any version control code management software.
The components were used to store the current working version from the dev server.
To use this approch you must make sure that only developers have access rights to these components.
I have very little experience with ASP.NET and I am doing some self-training before I start writing my first web site/application, which will be a calibration utility. How that utility works is not my concern right now. However, the utility eventually needs to end up embedded in someone else's web site, either just as a URL to the page with my code, or embedded (say, as an HTML frame or an iframe). To figure out the basics of this, I coded up two very simple ASP.NET web sites, a "parent" which contains the frameset, and a "child" which I am trying to put into one of the frames.
The parent's "Default.aspx" HTML code is basically this:
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<title>Parent Site Test 1</title>
</head>
<frameset cols="300,*">
<frame name="outer" src="parent.aspx" noresize></frame>
<frame name="inner" src="[what do I put here?]"</frame>
</frameset>
</html>
The "parent.aspx" page has only the most basic HTML in it:
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<title></title>
</head>
<body>
<form id="form1" runat="server">
<div>
I am the parent web form.
</div>
</form>
</body>
</html>
The child web site (as I have it now) lives in a separate VS2008 solution, for the purposes of this exercise, because I am trying to reproduce the conditions in which someone else's web site has to reference my calibration web page/site/thing. I was originally thinking there would be some way to package the entire child into a single DLL, and then there would be some way to tell the parent to use that DLL as the source for the child frame. This comes from my experience in the Java world - using JBoss and J2EE, this would be easily solved because the child would just be deployed as another EAR file.
Being completely inexperienced with VS2008 and ASP.NET, I spent quite a few hours on Google over the past few days trying to find an answer, to no avail.
Is what I'm trying to do reasonable; is it the right way to think about solving the problem?
Can I deploy the child as a fairly independent and self-contained web site (or web application... I'm still unclear on the differences) by somehow packaging it into a single DLL? If yes, then how do I actually create this DLL from my web site/application in VS2008, and how do I then reference it in the parent web site?
If I am totally off track here, how can I create this parent/child combination in some other way? The child (really, the calibration utility I will eventually write) does need to be in ASP.NET (with C#) but I don't have any control over the parent site, since it's someone else's code, and they just want to be able to drop in my utility.
Thanks for the help! The more specific you can be, the better. I am very new to ASP.NET and Visual Studio, though I do have plenty of experience programming in other languages and IDEs.
If you know the client also uses ASP.Net, you could build it as a User Control.
If you have IIS6 or higher, you can run both of the web applications and in your src="[what goes here]" you put the local URL of the child website (maybe http://localhost/ChildTestWebsite/child.aspx). Then when you load up http://localhost/ParentTestWebsite/Default.aspx you should see the frames.
To package it into a single DLL, I believe you have to make it just a user control like Joel said, otherwise you have the DLL + aspx pages.
What you should do depends on how the interaction between the parent and child is.
If the parent is not going to access any server-side functionality on the child, you can just reference to the absolute http path in the src on the frame tag. You might get security issues in some browsers if you try to access javascript methods and the 2 apps are on diferent web servers, but this is not .NET specific.
If the parent is going to access server side functionality, you need to provide the server side components somewhere in the parent project. This is more complex. I think you have to build all child pages as web controls that is included in a parent aspx page.
1: Build the child project as a webcontrol library of server controls that can be used by the parent. This is best approach conserning deployment. Everything is built into one single dll. The biggest disadvantage to this, is that server controls can only be developed in code. You have no visual designer to help you.
2: Create a Web Application project. In VS2008 you do this by "New Project" and then find the "ASP.NET Web Application" template. This means a web project where all code behind (everything inside the cs files) is build into a single dll. In this scenario, you create user controls (ascx files) that can be used by the parent page. The disanvantage of this is that user controls must be loacted on the runnin web app, so you must copy all ascx files to the deployed location of the parent web site. The dll must also be copied to a bin folder in the parent web site. Here you have the advantage that it is much simpler to design the GUI in VisualStudio. Designing the gui and code behind for ascx user controls are very similar to creating full aspx web pages.
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.
First shot at throwing a question on these boards so hopefully I can get some help, here goes:
I am working to start up the .NET practice at my client. We have 5 small scale .NET applications in place currently with a few them of them live into production. They're mostly small reporting pieces with some data entry/business logic functionality. Each of these applications is currently using the identical master pages.
What I mean is that there is a copy of the same master page in each application. They are all basic website->WCF->BL->DB tiered applications. So I have 4 copies of the same master page that I have to change when I make a change to it.
The client DOES NOT want to consolidate all of these into a single solution. They like the separation of applications across sites. I just don't want to continue dealing with the hassle of multiple updates for common elements (which there will be many more of across these applications).
The code is all stored in team foundation server. We also do NOT want to compile the master page into a .dll and deploy it.
Can anyone please make some suggestions as to how I can maintain a single copy of these common files (master, .css, etc) across my multiple applications.
thanks in advance
You might want to look at Sharing Master Pages in Visual Studio.
If that is no help then you could try using Build Events in Visual Studio. I would pick one of the projects to be my "Main Project" and only edit the master page from that project. When you build the project it would run a command that would copy that master page(if it had changed) to your set locations.
The client DOES NOT want to
consolidate all of these into a single
solution. They like the separation of
applications across sites. I just dont
want to continue dealing with the
hassle of multiple updates for common
elements (which there will be many
more of across these applications).
The code is all stored in team
foundation server. We also do NOT want
to compile the master page into a dll
and deploy it.
You eliminated the only two real options there. What all is in the master page? Would it be possible to extract the HTML UI elements to a single template or series of template HTML files and import those dynamically into the master page? You could then relocate the common HTML to an arbitrary URL and have the master page for each application pull it in dynamically.
Edit: I lied. You could also use a VirtualPathProvider like Sharepoint does to store the master page in a database or some other directory, but beware that VirtualPathProviders do not work in MediumTrust environments.
See:
http://msdn.microsoft.com/en-us/library/system.web.hosting.virtualpathprovider.aspx
If you are using Web Applications (compiled into a dll) rather than Web Sites you can do the following:
Right click on the folder you want to store the master page in
Select "Add Existing Item..."
Browse to the master page on the file system, and select both the .master and the .master.cs files.
Then, rather than clicking on the "Add" button, click on the little down arrow to the right of Add, this will bring up a little menu with the options: "Add" and "Add As Link"
Select "Add As Link" this will reference the file in your project, while leaving it in the original location in your dev environment - this allows you to edit it in either application, while keeping it up to date in the other applications.
Obviously if you edit the code behind, you'll need to re-compile the other projects before you deploy the changes to those sites.
This isn't available in web site projects as they rely on the file structure to work out what is in the project.
EDIT: Missed the css part. Obviously you won't be able to serve those files, so this should only work for the master page.
Don't know your scenario, so
IF you can control the DNS / virtual directories to the applications you could use a format like this:
c:\inetpub\wwwroot\Application1
c:\inetpub\wwwroot\Application2
c:\inetpub\wwwroot\Application3
c:\inetpub\wwwroot\Application4
c:\inetpub\wwwroot\Application5
and have your Master page at c:\inetpub\wwwroot\master.Master,
c:\inetpub\wwwroot\master.Master.cs,
c:\inetpub\wwwroot\master.Master.cs.designer
Then you could reference the single copy of the master page from /../master.Master. I gave this a quick shot with a precompiled master page to make sure I could reach back beyond my root. You might have to give it a shot to see.
We use our source control to create links to the shared files in all the places that we need it. So if you edit in one place, you just need to do a get latest and it will appear in the other places you have linked it.
I ended up going with the VPP route. I created a virtual path provider and built my master page into a DLL and this is working. Now I have a massive problem though in that a Content page whos master page is late bound through the codebehind throws validation/formatting hissy fits because it thinks its should be a stand along page. my CNTRL + K, CNTRL + D has broken on every page where I'm now sharing my master page. This is extremely frustring for me and the team