OdeToCode IC Logo

Q&A About the Community Starter Kit

Thursday, October 7, 2004
Here are some questions I received after last night’s presentation on the Community Starter Kit.

Q: Where does the WYSIWYG editor come from?

A: The WYSIWYG editor is an HTML component (HTC). In the CSK, you can find a file named HtmlTextBox.htc that implements the HTML editor component. The HTC file uses a mixture of HTML, JavaScript, styles, and object tags to implement the editor.

It looks as if Paul Abraham has broken out the HtmlTextBox.htc file from the CSK and repackaged the component into a standalone assembly. I haven’t tried this but it looks interesting. Another editor I've seen in applications is the control from from FreeTextBox.com. There is also an assortment of editors and other controls in the ASP.NET content management control gallery.

Q: Can we port the CSK to Oracle?

A: Backend portability was not in the design goals for the CSK. It is possible, but requires some work. First, there is a total of about 200 stored procedures and user defined functions (UDFs) in the SQL Server database you’ll need to port over to Oracle. Each class representing a content type in the domain model architecture of the CSK will also need to be modified – as they are using the SQL Server specific SQL provider classes of ADO.NET. The good news is, once you get all that done – it’s all downhill!

Q: Why do the ASCX files have no code-behind?

A: Unfortunately, I tried to cover too much in this presentation and didn’t get to address this issue properly. Usually when we build ASCX files, we drop controls in the ASCX and in the code behind the ASCX we tell the controls what to display. The CSK works a little differently. We still put controls into the ASCX but the controls themselves are highly customized and already know what they need to display.

The ASCX files then strictly serve as skins. They are simply there to layout where the controls will appear. There is no logic associated with the ASCX file – no code. Each control is customized to do a specific duty. For example, when you plop a community:Author control on the page, the Author control knows it has to display the author’s name for a piece of content. All of the logic is inside this web control - the skin file determines where the control will display.

Q: Are there any sites supporting fixes and customizations of the CSK?

A:  Three I know of, there could be more…

Stephen Redd’s Site (full of CSK Articles, Mods, and Fixes)
Dave Rank’s Personal Web Site
Matthew Roche’s CSK Resources

Q: What is the ASP.NET vulnerability you were rambling about?

A: This is not related to the CSK – it’s a bug in the ASP.NET runtime and is very serious. You need to view the following Microsoft documents and implement the suggested fix as soon as possible until a patch can be provided.

What You Should Know About a Reported Vulnerability in Microsoft ASP.NET
Programmatically check for canonicalization issues with ASP.NET


tim nishimura Saturday, July 23, 2005
In one of your Q&A, you give the reason why there is no code-behind. However, if you want to globalize the CSK, the code-behind page becomes indispensable for the skins. In many skins, short English titles are often used, so that you must either create the same skins under different language directories, or use the code-behind page to supply the titles in different languages. The first method of placing the same skins in different language directories is somewhat cumbersome and should be avoided unless some changes in the page design is necessary because of the requirement from a particular language culture. Besides, some Web servers intentionally take away the double-byte language fonts, so that the question marks are displayed instead of ugly gibberish letters when viewed by browsers that do not understand the double-byte fonts. In this case, the only way out is to supply the double-byte languages such as Japanese, Chinese or Koreans from the code-behind pages.
scott Saturday, July 23, 2005
Good point - globalization is obviously a topic I had not thought about.
Jody W. Tuesday, August 2, 2005
My website also supports the CSK including several performance and security fixes, as well a fair collection of Articles I have written to expand the overall functionality of the kit.

In regards to code behind, skinning, and globalization. I wrote a Template MOD which allows the actual skin to be overridden at design time. By adding code that intercepts from the HTTP browser context in the SkinnedCommunityControl.cs a template-Suffix could be added and skins could programically be presented in the proper language without need to create new directories. The Template MOD automatically defaults back to the assigned Theme and Default Theme if not found. So whatever skins are not developed for a language - will not disrupt the presentation process.

Example: Articles_Article.ascx presents stock article display page.

Make a copy of the ascx file and name it Articles_Article-Fr.ascx and add the following to the page:

<%@Page Culture="fr-FR" Language="C#" %>
<% @Import Namespace="System.Globalization" %>

If the code modification in the SkinnedCommunityControl.cs works properly then the Articles_Article-Fr.ascx should be displayed...

Its a hack of sorts perhaps but for someone that needs to support it - it will most likely work for them.

The same process can be applied to the pulling of data from the DB for content display by modifying the [Module]Utility.cs to to either use strings to store Stored Procedure names to call when adding, editing, or retrieving language specific content. Naturally still columns would need to be added to the content tables for the content to be stored in additional languages but not an overall daunting task if really desired - just time consuming. But I will readily admit I do not do globalization just thought I would pass along a idea that may (or may not) work.


scott Wednesday, August 3, 2005

Thanks for the link. I've bookmarked your site because there is a lot of good information to dig into there.
Comments are closed.