使用的HtmlTextWriter来渲染服务器控件？ [英] Using HtmlTextWriter to Render Server Controls?

问题描述

我在写我的ASP.NET服务器控件的 RenderContents（）方法。该方法使用的HtmlTextWriter 对象以呈现输出的内容。对于控制我写，使用的HtmlTextWriter 的方法，看起来这将需要大量code线的打开和关闭每个标签，并添加每属性流。最后，我觉得我要与code这是一个很大的时间比它需要到结束。

我在想，如果我用了一个可链接的类，如的StringBuilder ，我的code会有很多清洁阅读和更容易编写。

我想知道是，没有任何理由使用的HtmlTextWriter 对象来呈现我的整个控件的内容？除了安全检查（我假设），它包括以确保你不写标签以错误的顺序或创建无效的标记，我没有看到一个原因。

现在看来似乎会更容易只是做这样的事情：

 保护覆盖无效RenderContents（HtmlTextWriter的输出）
{
    StringBuilder的S =新的StringBuilder（）;
    s.Append（手）
     .Append（的）
     .Append（字符串）;    output.BeginRender（）;
    output.Write（s.ToString（））;
    output.EndRender（）;
}
 

是否有任何理由，这将是一个坏主意？

更新

在回答的迈赫达德Afshari 答案：

 我也没多想有一个实例单独的的StringBuilder 对象的内存需求。怎么样使得对于HtmlTextWriter的包装，以便它可以被链接，这样的额外字符串不言。

 公共类ChainedHtmlTextWriter
{
    私人的HtmlTextWriter _W;
    公共ChainedHtmlTextWriter（HtmlTextWriter的作家）
    {
        _W =作家;
    }    公共ChainedHtmlTextWriter写＆LT; T＆GT;（T值）
    {
        _W.Write（值）;
        返回此;
    }    公共ChainedHtmlTextWriter的WriteLine＆LT; T＆GT;（T值）
    {
        _W.WriteLine（值）;
        返回此;
    }
}
 

解决方案

我在一个应用程序，开发者跟着你正在探索可怕的路径工作。这让人回想起当你不得不编写吐出HTML code你自己的ISAPI的dll的日子。这是一个常数头痛的工作。如果你的code主要是字符串，那么什么是错的。

大多数这种类型的，我改变我的实例化服务器对象，根据需要配置它们的属性，然后告诉他们.RenderControl（作家）的code的。这使得code更容易阅读和使用。如果由此带来的开销命中的表现，我愿意接受它（事实上，应用程序通常运行得更快我做了我的变化后，据传所以这是不是这样的，但我没有异形我的code）。

一个简单的缺点硬编码你的东西在字符串是当HTML标准的变化。在code我在写于04/05的工作，从那时起＆LT; BR＆GT;已经成为＆LT; BR /＆GT;和大写的HTML标签不洁净了，等等。如果他们使用服务器控件被那些服务器控件已经改变了他们的HTML输出没有我们需要做什么。这仅仅是一个简单的例子。

编辑：哦，顺便说一句和，BeginRender和EndRender没有任何实现。他们是占位符，您覆盖，并在HtmlTextWriter的派生类提供自定义的功能。

EDIT2：有时它是一个有点繁重到的总是的使用服务器控件，如容器和材料。我会做很多.Controls.Add（），然后后来呈现的容器。所以有时候我这样做：

  writer.AddAttribute（HtmlTextWriterAttribute.ClassmyContainerClass）;
writer.RenderBeginTag（HtmlTextWriterTag.Div）;
//做一些东西，.RenderControl一些其他的控制等
writer.RenderEndTag（）;
 

如前所述，这将使正确的HTML即使在未来一个div变化的HTML，因为我没有任何硬codeD字符串。

I'm writing the RenderContents() method of my ASP.NET server control. The method uses an HtmlTextWriter object to render the output content. For the control I'm writing, using the HtmlTextWriter's methods seems like it will require a lot of lines of code to open and close every tag and add every attribute to the stream. In the end I feel like I'm going to end up with code that is a lot longer than it needs to be.

I was thinking that if I used a chainable class such as StringBuilder, my code would be a lot cleaner to read and easier to write.

What I was wondering was, is there any reason to use the HtmlTextWriter object to render my entire control's contents? Other than the safety checks (I'm assuming) it includes to make sure you don't write tags in the wrong order or create invalid markup, I don't see a reason.

It seems like it would be easier to just do something like this:

protected override void RenderContents(HtmlTextWriter output)
{
    StringBuilder s = new StringBuilder();
    s.Append("lots")
     .Append("of")
     .Append("strings");

    output.BeginRender();
    output.Write(s.ToString());
    output.EndRender();
}

Is there any reason why this would be a bad idea?

Update
In response to Mehrdad Afshari's answer:
I didn't think much about the memory requirements of having a separate StringBuilder object instantiated. What about making a wrapper for HtmlTextWriter so that it can be chained so that an extra string isn't made.

public class ChainedHtmlTextWriter
{
    private HtmlTextWriter _W;
    public ChainedHtmlTextWriter(HtmlTextWriter writer)
    {
        _W = writer;
    }

    public ChainedHtmlTextWriter Write<T>(T value) 
    { 
        _W.Write(value); 
        return this; 
    }

    public ChainedHtmlTextWriter WriteLine<T>(T value)
    {
        _W.WriteLine(value);
        return this;
    }
}

解决方案

I work on an application where the developers followed the horrible path you're exploring. This harkens back to the days when you had to write your own ISAPI dlls that spit out html code. It is a constant headache to work in. If your code is mostly strings, then something is wrong.

Most of the code of this type that I change I instantiate server objects, configure their properties as desired, and then tell them to .RenderControl(writer). This makes the code much easier to read and work with. If there is a performance hit from the overhead this brings, I am willing to accept it (in fact, the application generally runs faster after I've made my changes, so anecdotally this isn't the case, but I haven't profiled my code).

One simple drawback to hard-coding your stuff in strings is when HTML standards change. The code I work on was written in 04/05, and since then <BR> has become <br /> and uppercase html tags aren't kosher anymore, etc. If they had been using server controls, those server controls have changed their outputted html without us needing to do anything. This is just one simple example.

EDIT: Oh, and btw, BeginRender and EndRender don't have any implementation. They are placeholders for you to override and provide custom functionality in a HtmlTextWriter-derived class.

EDIT2: Sometimes it's a bit onerous to always use server controls, like for containers and stuff. I'd be doing lots of .Controls.Add() and then render the container later. So sometimes I do this:

writer.AddAttribute(HtmlTextWriterAttribute.Class, "myContainerClass");
writer.RenderBeginTag(HtmlTextWriterTag.Div);
// do some stuff, .RenderControl on some other controls, etc.
writer.RenderEndTag();

As mentioned, this will render correct html even if the html of a div changes in the future, cause I don't have any hard-coded strings.

这篇关于使用的HtmlTextWriter来渲染服务器控件？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！