I'm recently assigned a major project of migrating an existing Coldfusion application to ASP.NET. I started by converting inline queries to Sql stored procedures and proceed to convert cfm pages to aspx one by one. Are there any good guidence to follow in this practice? Any good recommendations of facilitating tools would be appreciated.

Thanks a lot.

Yubo

Depending on how many CFML pages you have to rewrite and how long you expect it to take, it may be faster and cheaper to use BlueDragon.NET to simply redeploy the CFML pages onto ASP.NET:

http://www.newatlanta.com/products/bluedragon/index.cfm

BlueDragon.NET is implemented as 100% managed code, and allow you to integrate with ASP.NET by sharing application and session scopes, and by using COBJECT to invoke any .NET framework objects.

BlueDragon.NET is certified for Windows Server 2003, New Atlanta (the company that makes BlueDragon.NET) is a Microsoft Gold Certified ISV Partner, and Microsoft has published a case study about BlueDragon.NET here:

http://members.microsoft.com/CustomerEvidence/Search/EvidenceDetails.aspx?EvidenceID=3606&LanguageID=1

Finally, MySpace.com, which is one of the most heavily trafficked sites on the Internet, has switched from ColdFusion to BlueDragon.NET:

http://www.myspace.com

Let me know if you have any questions or would like further details (or would like to have a salesperson contact you).

Thanks for your advice. However this is our house keeping effort to build it as part of the core solutions, which uses zero third party components.

Yubo

.NET is a different animal than CF.  Everything is an object whether you like it or not.  Even your aspx page becomes an object (though you may not notice it at first).  Converting from one page to another page may not be the best approach.  If your CF app seperated out business and presentation layers then your business layer would become your re-usable pre-complied assemblies (dll's) and your presentation would be in the aspx files.  That's a rough assumption but you get the idea.

vr, Rich

Let me try answering the actual question. 

I'm having to do the same thing - convert over CF code to asp.net.   It's actually not too bad.  I'm using alot of inline code.   I built a base page code-behind page and inherit it for all my other pages to make data access easier.   I use almost exclusively datasets and make use of the code behind whenever possible   I've moved alot of places where there was CF code in a seperate file to the onclick function in the code-behind.  I moved most of my SQL code to stored procedures but got a little tired of that  - I ended up building a little piece of code to retrieve my SQL (mostly for inserts & updates - seems pointless to put them in a proc)  from a database right into the select of my datasets.  Makes it a lot easier to get the code up and running.   From one of your other posts, I see you are using no third parties.  This should make it even easier. 

Rather than populate my input forms inline, I convert them all to controls and populate them in my load routines.  The validation controls are much easier to work with than the CF validations.   Also, learn how to use the CustomValidator (if you don't already)  You can use it to achieve the custom validations that CF has.

So basically inline it where you can to preserve the CF 'flow' and shift to the code behind when it can help make the code more legible.  Hopefully you aren't dealing with any fusebox code (god I hated that) or anything like that.    I have yet to find any CF code that I couldn't translate.  I make a lot of use of <!-- #include to simulate the CF_Include on shared coded. 

Blue dragon has a lot of issues - I was in on a test at a (very large) client for it.  They passed on it. You're much better off converting it and escaping CF, though forget coding web pages as fast as CF.  However, I believe the integrated debugger makes up for this loss (and of course having a real language is great - I hate the whole CF script thing)

Anyway, don't know if any of this helps - if you run into some specfic translation issues I might be able to help.

Regards,

Nick H

Thanks for the detailed response.

I have no problem with data access layer and page validations conversion from Cfm to aspx. I did run into a problem yesterday with dynamically populated controls on the page. For example, a list of asp:CheckBox(s) are populated from the result of a database query, the number of which is determined at run time. I could not find a way to specify the "Checked" property of each checkbox. The following two methods does not work:

1. the string "column" here can only be determined at run time, but DataBinder.Eval method doesn't allow a variable as a parameter.

<td width='10%'><asp:CheckBox ID="Checkbox8" Runat=server Checked='<%# DataBinder.Eval(Container.DataItem, "column") %>'></asp:CheckBox></td>

2. <asp:CheckBox ID=ckRight Runat=server Checked='<%#isChecked%>'></asp:CheckBox>

using this isChecked property does not generate expected result.

If you have any thoughts, I'd appreciate it.

Thanks.

Yubo

Nick, you say, "Blue dragon has a lot of issues - I was in on a test at a (very large) client for it.  They passed on it."

Can I just remind everyone that moving to CFMX can have "a lot of issues". It's all about perspective, as well as the state of your code. There are plenty of sites that move to BlueDragon with no issues at all, and some that have minor ones. There can be some who may have major ones. It's a little unfair to castigate it entirely like that.

We all know that there are some who would pitch CF entirely into the bin. Sometimes their assertions are based on old knowledge, or even second-hand knowledge. I realize, Nick, that it may even have been just recently that you tested, so that may not be the issue here. Let's just all remember how we feel when someone spews on CF. We don't like it, and we know many who would not agree with the accusations. I'm just saying that I (and hundreds of happy customers) can say the same about BD, and especially BD.NET.

If you have a LOT of legacy CFML, we feel that there's simply no better way to get that running in the better platform of .NET than to use BD.NET.

/charlie

You might want to check out the events on the asp:checkboxlist or the asp:checkbox control.  Both have events such as OnLoad, OnDataBinding, OnPreRender.  During which you can fire off a function that will determine if the checkbox should be checked or not by flipping the boolean 'Checked' property.  I had to something similar on a DataList control so I fired off a function on the OnItemDataBound event.

vr, Rich

Perhaps I'm being a bit harsh/unfair to BlueDragon - I should have said compounding CF issues by inserting yet another layer, whatever that layer is,  is a bad idea.  It's a band-aid.  I'm not sure how moving to CFMX relates to the questions, but ok.  I don't consider Blue Dragon a platform to move to - it's a conversion layer.    That said, the testing was done about a year and half ago. 

As far as my background goes - I'm a highly experienced CF coder, among other languages. 

BTW Charlie, do you work for BD?

Regards,

Nick H

All of the above is, of course, my opinions. 

Yubo,

Ack, we are hijacking your thread for political discussions - my apologies.  We should be answering your questions.

Question: You said the number of checksboxes is determined at runtime?  Is that what you meant?  Are you creating the checkboxes in code?   Is the query in the code behind?   Or are you using a code block loop to generate them?

Regards,

Nick H

Hi, thanks. I still have not figured out that solution.

Yes, the number of the list of checkbox is determined at runtime. the DataSet is as follows, where 0 and 1 are the checkboxes checked values, (the number of 0 and 1s vary by the query):

Developer 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0
End User 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0
Project Manager 1 1 1 0 0 0 1 0 1 0 1 0 0 0 0 0 0 0 1
Quality Assurance 1 1 1 0 0 0 1 0 1 0 1 0 0 0 0 0 0 0 1

The two ways I tried to create checkboxes with correct 'Checked' property failed:

1) Imbed CheckBoxes in a repeater

<asp:Repeater ID="rpEHierarchy" Runat=server>

<ItemTemplate>

<tr>

<td width='20%'><%# DataBinder.Eval(Container.DataItem, "Role") %></td>

for loop....

colName = DataSet.Tables[0].Columns[i].ColumnName;

<td width='10%'><asp:CheckBox ID="Checkbox8" Runat=server Checked='<%# DataBinder.Eval(Container.DataItem, colName ) %>'></asp:CheckBox></td> </tr>

end loop

the colName is not acceptable as a variable in DataBinder.Eval();

2) Using while loop to pupulate checkboxes:

<% while(n<%=role%><% while(n<%if(ShierarchyDS.Tables[0].Rows[n][2].ToString()=="True") isChecked=true; else isChecked = false; %><%

 int j=0; isChecked = false;

   while loop for rows
    while loop for columns

    {%>
      <td  width='10%'>
      <%if(DataSet.Tables[0].Rows[n][2].ToString()=="True") isChecked=true;
        else isChecked = false;
      %>
      <asp:CheckBox ID=ckRight Runat=server Checked='<%#isChecked%>'></asp:CheckBox>
      </td>
 end loop

end loop

isChecked  here is a property.

but this approach would not generate desired checked values.

 

   <%n++; } if(n<% }%><%n++; } if(n<% }%><%n++; } if(n<% }%><%n++; } if(n<% }%><% while(n<%=role%><% while(n<%if(ShierarchyDS.Tables[0].Rows[n][2].ToString()=="True") isChecked=true; else isChecked = false; %><%n++; } if(n<% }%>

<% while(n<%=role%><% while(n<%if(ShierarchyDS.Tables[0].Rows[n][2].ToString()=="True") isChecked=true; else isChecked = false; %><%n++; } if(n<% }%>

 

Nick, yes, sorry, I do work for New Atlanta. My email client would of course place that in my signature but typing this email here I didn't think to add it. (Actually, I'd also presumed it was clear from my previous postings in this forum, but of course it's reasonable that someone in a new thread may not have seen previous ones.)

Your comment about being a highly experienced coder sounds like you're trying to defend against some attack by me on your skills. I wasn't at all. I was just asking whether your experience with BD was contemporary. Glad to hear it was about 18 months ago. I can promise you that (just as CFMX has had multiple hotfixes and point releases since then), BlueDragon 6.2.1 would be a very different experience than your attempt back then.

But you equate BD with a Bandaid, and "another layer". Just want to clarify: it's not another layer "on top of CF", if that's what you meant. It is a replacement for CF. Just as CFMX runs on top of the J2EE framework, BD.NET runs on top of the .NET framework. CF doesn't run on .NET at all, so if one wants to run CFML natively on .NET, BD.NET is the only choice.

This isn't a "political" discussion, nor is it a sales pitch. It's just a fact. The sad thing, again, is that just as some who don't use CF want to cast it in a negative light, similarly those in the CF community who don't use BD or don't understand it will often regard it negatively as well. But Microsoft certainly appreciates what BD.NET can do. They did a whitepaper on it at the MSDN site:

http://members.microsoft.com/CustomerEvidence/Search/EvidenceDetails.aspx?EvidenceID=3606&LanguageID=1

Also, they had me do a 2-part webcast this week, showing the benefits of running CFML natively on .NET. Just finished the second part. When I have the URLs for the recordings, I'll be happy to share them for those interested.

Finally, Nick, you say you "don't consider Blue Dragon a platform to move to". Well, we're saying .NET is the platform. BlueDragon isn't a "conversion layer". Not at all. Your CFML remains CFML. We just provide the runtime for it atop .NET, again just like CFMX (and Java versions of BlueDragon) offer a CFML runtime atop J2EE. There's no "conversion", nor "migration". It's simply about redeployment.

If one wants to use ASP.NET, go for it. But if one has a large legacy investment in CFML and CFML developers, BD.NET just helps smooth the transition of getting them onto .NET, converting code (if ever) at their own pace and affording them the time to learn .NET as well as they know CFML Hope that's helpful.

/charlie
Chief Evangelist
New Atlanta Communications, LLC

Charlie - good enough  - we just have a difference of opinions on the matter and I appreciate the professional manner in which you have delt with it. I understand what you are saying, I just disagree with the idea of it  - not BD in particular.  I should have made this plain in my original post and for this I apologize. (and yes I do understand BD isn't on top of CF - it's on top of .NET - and  I should have said 'interpreter' layer instead of conversion )

Yubu - you are running into EXACTLY the same problem I have had ( and trying many of the same solutions) - the inability to easily set <ASP:xx> parameters via a loop or repeater.   I've yet to get an answer to it so I'm not going to be of much help.  My issue was in trying to use linkbuttons - I finally just gave up and used traditional anchors.  It really seems like ASP.NET is not setup to make use of the code blocks - which really sucks.   Having both code blocks and code behind would be extremely powerful and put it nearly on RAD speed of CF - and it may yet be there somewhere, but I've yet to figure it out.   The problem is the loop in the <% %> code is not executed at the same time as the <ASP:xx> components are built. 

What I would try for your issue is a place holder combined with building the check box components manually in the code behind.  I THINK this would work - I have yet to try it.

Regards,

Nick H

 Is there a tool that will convert CFML to asp.net (NOT BLUEDRAGON) a straight conversion?!?!?!?!?!?!

Thanks

 

I think you're chasing a pipe dream. There is none I've ever heard of, and I can't imagine there ever will be. Coding in traditional CFML is SO different than coding in ASP.NET. It just would never work for an automated tool to do that conversion.

That said, many who extol the benefits of converting an app from CF to something else (making it more maintainable and scalable) would find that if they just rewrote it in CFML (staying on CF or BD) would see many of the same benefits. Often the improvements come both from using more modern coding practices (separation of view code from business logic), as well as simply from having a fresh start to incorporate a better understanding of the problem domain, rather than using duct tape and rubber bands to add functionality to an old system. In that respect, coding in CF is not that different from many other procedural languages. But since 2002 it's been possible to write far more reusable, component-oriented code in CFML. It's just that most have never taken the time to rewrite old apps to leverage that.

Still, I'm not denying that if you want it running on .NET (and you don't want to use BD.NET to get there), then you have no choice but to rewrite. Maybe you have no more CFML developers, or you have a pool of ASP.NET developers available. Even if you don't want to use BD and really want pure ASP.NET code in a conversion from CFML, you may still want to contact them (sales@newatlanta.com) and ask about possible services to do such conversion.  

(BTW, no, I don't work for New Atlanta. Though I did when this thread started in early 2006, I left two years ago this month. It's no knock on the product. I just wanted to be able to help people as much with CF challenges as with BD ones. And I still believe BD.NET's the best way--indeed the only way--for a shop to get their CFML apps running natively on .NET. CF8 has added new features to enable greater integration between CFML and .NET, but to truly run CFML *on* .NET, BD.NET is the way to go.)