Question

Dans le scénario WebForms normal, toute URL relative à la racine (par exemple, ~ / folder / file.txt) à l'intérieur de fichiers CSS tels que:

.form { background-image: url(~/Content/Images/form_bg.gif); }

sera automatiquement résolu lors de l'exécution si je le spécifie

<head runat="server">

Dans la page de référence.

Toutefois, cela ne se produit plus sur un site Web ASP.NET MVC Beta1.

Existe-t-il un moyen d'activer cette fonctionnalité sans recourir à des hacks ou à un fichier de chargeur CSS? Comme peut-être HttpModules ou quelque chose?

Ou est-ce que je ne dessine pas correctement mon site Web? Qu'est-ce qui est censé être un bon design?

Etant donné que ASP.NET WebForms d'origine possède déjà cette fonctionnalité, je préférerais utiliser les fonctionnalités existantes si possible. Mais je n'ai pas la moindre idée.

Cette application Web sera déployée dans plusieurs environnements où le dossier ~ racine pourrait ne pas être évident.

MODIFIER: je parle de l'URL du contenu du fichier et non de l'URL du fichier lui-même.

Était-ce utile?

La solution

Je ne voudrais pas m'embêter avec le caractère ~ de recherche automatique de la racine. Je comprends que vous souhaitiez que la même solution fonctionne lorsque le répertoire racine diffère d’un déploiement à l’autre, mais vous ne devriez pas rencontrer de problèmes dans le document CSS en utilisant des chemins relatifs. Les chemins dans le document CSS (vers l'URL de l'image dans votre exemple) seront toujours relatifs à l'emplacement du fichier CSS, quel que soit le chemin de la page qui charge ce fichier CSS. Donc, si vos images sont dans ~ / Content / Images et vos feuilles de style dans ~ / Contenu / Stylesheets , vous pourrez toujours utiliser image-arrière-plan : url (../ Images / form_bg.gif); et cela fonctionnera quel que soit l'emplacement de la page qui charge la feuille de style.

Y a-t-il une raison pour que cela ne fonctionne pas?

Autres conseils

Une astuce que j'ai utilisée par le passé consistait à donner à mon fichier CSS une extension .ASPX et à définir la propriété ContentType dans la signature de page:

<%@ Page Language="C#" ContentType="text/css" %>

body {
    margin: 0;
    padding: 0;
    background: #C32605 url(<%= ResolveUrl("~/Content/themes/base/images/BodyBackground.png") %>) repeat-x;
    font-family: Verdana, Arial, sans-serif;
    font-size: small;
    color: #d7f9ff;
}

Cela garantira que le fichier CSS passe par le framework ASP.NET et remplace le code côté serveur par votre chemin relatif.

Ici are certaines ressources sur la mise en oeuvre de IHttpModule pour intercepter les requêtes Web vers votre application ...

Écrivez / adaptez-en un pour vérifier le type de fichier (par exemple, un pseudocode: if (la requête se termine par ".css") ...)

utilisez ensuite une expression régulière pour remplacer toutes les instances de " ~ / " avec System.Web.VirtualPathUtility.ToAbsolute ("~ /" "

Je ne sais pas ce que cela va entraîner pour les performances, si chaque requête est filtrée avec ce type de filtre, mais vous pouvez probablement manipuler votre fichier web.config et / ou vos routes d'URL MVC pour acheminer toutes les requêtes .css via ce type de filtre en le passant pour d’autres fichiers.

À bien y penser, vous pouvez probablement obtenir le même effet dans une application ASP.NET MVC en pointant toutes vos références CSS vers un controller.action spécial qui effectue ce type de prétraitement à votre place. Je doute que ce soit aussi performant qu'un IHttpModule.

Si vous essayez d'analyser ~ / dans n'importe quel fichier, y compris les fichiers texte, javascript, etc., vous pouvez écrire un gestionnaire qui lui attribue un filtre. rechercher ces chemins ... par exemple ...

public class StringParsingFilter : MemoryStream {

    public Stream OriginalStream {
        get { return this.m_OriginalStream; }
        set { this.m_OriginalStream = value; }
    }
    private System.IO.Stream m_OriginalStream;

    public StringParsingFilter() : base() {
        this.m_OriginalStream = null;
    }

    public override void Flush() {
        this.m_OriginalStream.Flush();
    }

    public override void Write(byte[] buffer, int offset, int count) {

        //otherwise, parse for the correct content
        string value = System.Text.Encoding.Default.GetString(buffer);
        string contentType = HttpContext.Current.Response.ContentType;

        //Do any parsing here
        ...

        //write the new bytes to the stream
        byte[] bytes = System.Text.Encoding.Default.GetBytes(value);
        this.m_OriginalStream.Write(bytes, offset, count + (bytes.Length - buffer.Length));

    }

}

Et vous écrirez un gestionnaire personnalisé pour savoir quand attribuer ce filtre ... comme ci-dessous ...

 public class FilterControlModule : IHttpModule {

    public void Init(HttpApplication context) {
        HttpApplication oAppContext = context;
        oAppContext.BeginRequest += new EventHandler(_HandleSettingFilter);                        
    }

    private void _HandleSettingFilter(object sender, EventArgs e) {

        //You might check the file at this part to make sure
        //it is a file type you want to parse
        //if (!CurrentFile.isStyleSheet()) { return; }
        ...

        //assign the new filter
        StringParsingFilter filter = new StringParsingFilter();
        filter.OriginalStream = HttpContext.Current.Response.Filter;
        HttpContext.Current.Response.Filter = (Stream)filter;

    }

}

En réalité, il aurait peut-être été plus facile de dire "recherchez les modules IHttp". mais c’est un code que j’ai utilisé pour analyser des fichiers pour des chemins autres que ASP.net.

Vous devrez également modifier certaines choses dans vos paramètres IIS pour permettre l'analyse des fichiers en définissant l'ISAPI ASP.net comme un caractère générique pour tous les fichiers traités. Vous pouvez voir plus sur ce site , si vous utilisez IIS6, c’est ...

Vous pouvez également l'utiliser pour modifier n'importe quel type de fichier afin d'attribuer des filtres pour les images, d'autres pour le javascript, les feuilles de style ou ... vraiment tout ...

Vous pouvez utiliser un rédacteur d'URL pour corriger l'URL lors de l'arrivée de la demande, bien que Je ne suis pas sûr qu'il soit aussi élégant qu'un hack dans ce cas.

J'ai créé une classe util PathHelper qui me donne tous les chemins dont j'ai besoin. Par exemple

<link href="<%=PathHelper.CssUrl("FormulaIndex.css")%>" rel="Stylesheet" type="text/css"/>

me donne l'URL complète correcte à l'aide de System.Web.VirtualPathUtility.ToAbsolute () et de ma propre convention (content / css / yourFile.css).

J'ai fait la même chose pour js, xml, t9n, photos ... Il est central, réutilisable et il ne me reste plus maintenant qu’à modifier une ligne pour capturer le déplacement du dossier de scripts de content / js vers des scripts dans tous mes sites Web et toutes mes pages.

Un geste débile si vous me le demandez, mais c'est la réalité dans la version bêta actuelle: (

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top