2010-11-02 13 views
7

Estoy trabajando en una biblioteca de recursos compuestos en tiempo de ejecución para ASP.NET WebForms/MVC. Respaldo tanto el WebForms ASP.NET estándar a través de WebControls y recientemente también he agregado soporte para ASP MVC Html Helpers. Una característica que soporto actualmente con WebForms WebControls es el concepto de definiciones de recursos "Parciales" donde un recurso se puede combinar en las páginas Master/View, etc.Ayuda con ASP.NET MVC HtmlHelper API Diseño

Al implementar el equivalente MVC, no estoy seguro de cuál es la mejor la práctica es? Actualmente estoy inclinando hacia un diseño algo como:

página maestra

<% using (Html.CreateCompositeResourcePartContext()) 
    { 
    Html.CompositeCssResourcePart(
     "ResourceName", 
     new[] { "/Styles/SharedStyle1.css", "/Styles/SharedStyle2.css" } 
    ); 
    %> 
    <asp:ContentPlaceHolder ID="head" runat="server"> 
    </asp:ContentPlaceHolder> 
<% } %> 

que creará un envoltorio de "contexto" alrededor de la cabeza ContentPlaceHolder.

Ver página

<asp:Content ID="HeadContentPlaceholder" ContentPlaceHolderID="head" runat="server"> 
    <% Html.CompositeCssResourcePart(
    "ResourceName", 
    new[] 
    { 
     "/Styles/PageStyle5.css", 
     "/Styles/PageStyle6.css", 
     "/Styles/PageStyle7.css" 
    }) %> 
</asp:Content> 

Así que cualquier páginas de vista puede extender la definición del recurso parcial, como se ha visto anteriormente.

las preguntas que tengo:

1) A diferencia de todos mis otros HtmlHelper, estas extensiones no escriben inmediatamente el fragmento de HTML, sino más bien esperar hasta que se dispone el contexto. ¿Deberían estas extensiones estar fuera del ViewContext en su lugar (u otro objeto)?

2) Personalmente creo que el concepto de "usar" tiene sentido para envolver un bloque de código en lugar de separar las llamadas a BeginCompositeResourcePartContext/EndCompositeResourcePartContext, ¿estaría de acuerdo? Si no, ¿qué hay de mejor con las llamadas a métodos separados?

Cualquier comentario sobre lo anterior sería muy apreciado. Si se requieren más detalles, házmelo saber.

Editar

Para aclarar ... el bloque dentro de la cabeza de la página Master y la posterior referencia en el lado de una página de vista se combinan juntos en un solo recurso. Así que cuando se dispone el contexto de CompositeResourcePartContext, los seis archivos se combinan en a sólo un archivo CSS y escriben como una sola etiqueta de enlace (o script, CSS sprites etc)

<link rel="stylesheet" type="text/css" href="/MyMergedStyleSheet.css" /> 
+0

No estoy seguro de qué le compra este ayudante. ¿No es eso para lo que están los marcadores de posición de contenido en primer lugar? –

+0

@John: la idea es que cada llamada a Html.CompositeCssResourcePart definirá una parte de un recurso compuesto (es decir, se fusionará en un único archivo cuando se elimine el contexto). Como tal, necesito un método para recopilar todas las partes antes de que se pueda representar una etiqueta de enlace/script a medida que se genera la URL de todos los recursos a los que se hace referencia. ¿Tiene sentido? –

+0

'usar' tiene sentido en este contexto, pero no puedo comentar más allá de eso. –

Respuesta

4

Después de pensarlo un poco más de pensamiento (y consultar a un colega) siento que la mejor opción es seguir con mi plan original de no contaminar mi ASP .NET MVC API con el concepto de definiciones de recursos "parciales" (funciona para WebControls, pero no es tan bueno con MVC en mi opinión).Antes de considerar una extensión HtmlHelper explícita para este caso en mi biblioteca, he sugerido que el problema puede ser manejado mediante la definición de un método de extensión personalizada de la siguiente manera:

public static class CustomXpediteExtensions 
{ 
    private static readonly IEnumerable<String> SharedCss = new[] 
    { 
     "/Styles/SharedStyle1.css", 
     "/Styles/SharedStyle2.css", 
     "/Styles/SharedStyle3.css" 
    }; 

    public static MvcHtmlString CustomCompositeCssResource(this HtmlHelper htmlHelper, params String[] resources) 
    { 
     return htmlHelper.CompositeCssResource(SharedCss.Concat(resources)); 
    } 
} 

y luego simplemente hacer referencia a esa extensión personalizada (o constante, etc. .) en la página de visualización.

<asp:Content ID="Content2" ContentPlaceHolderID="head" runat="server"> 
    <%= Html.CustomCompositeCssResource(
     "/Styles/PageStyle5.css", 
     "/Styles/PageStyle6.css", 
     "/Styles/PageStyle7.css" 
    ) %> 
</asp:Content> 

Esto le permitirá no repites la hora de combinar los recursos compartidos (es decir, garantizar la coherencia) y, finalmente, manejar el caso.

Voy a dejar esto abierto por un tiempo para ver si hay algún comentario al respecto; pero a menos que se haga un buen caso sobre por qué esto no es aceptable, creo que es la respuesta.

+0

Brillante, estoy robando esto ... –

2

Parece como una gran idea, pero podría servir mejor como parte del proceso de compilación. Podría crear fácilmente un CSS combinado para páginas individuales utilizando una plantilla T4, y quizás una convención de nomenclatura para agregar esa referencia CSS a su página. Algo así como:

<%: Html.MergedStyleSheet() %> 

pudo salida:

<link rel="stylesheet" type="text/css" href="/Content/ControllerName/ActionName.css" /> 
+0

He utilizado tareas de compilación en el pasado, y eso definitivamente es una opción. La principal ventaja que veo en el enfoque de tiempo de ejecución es que puede definir sus recursos en cada página casi como lo haría habitualmente y puede cambiar fácilmente entre los modos minified/combinado y de depuración sin requerir un esfuerzo adicional; Además, no tiene que preocuparse por mantener las tareas de compilación o los problemas de control de versiones, etc. Además, al manejar CSS Sprites, personalmente me gusta ver la definición de sprite directamente en la página que la está consumiendo. Mi interés está en la API propuesta para el escenario anterior que todavía tengo que cubrir. –

Cuestiones relacionadas