Static content linking

Last post 05-13-2008 7:13 PM by nagir. 4 replies.

Sort Posts:

  • Static content linking

    05-09-2008, 2:51 AM
    • Loading...
    • nagir
    • Joined on 01-09-2006, 7:01 PM
    • Australia
    • Posts 87

    Hi,

    Sorry for a long post. I didn't mean to do it :)
    I tried to structure my thought, but sorry if I failed :) I probably had to write a blog post.

    While Routnig is a great thing and it allows easy changing the structure of URL, it doesn't work with static content.
    So changing routing can just break some pages (when "direcory" structure is changed).

    Main 2 problems:

    1. Reference static resource from page (relative paths are not, generally, preserved after routing is changed) Good sample.
    2. Reference dynamic page from static resource. For example, new Ajax.Request("../../Home/RetrieveUsersOnline.aspx"). It will be broken after changing routing that produces link "/Users/Online/GetTop" instead first one.

    Also with fixed file structure I usually use combination of ASPX+CSS+JS located in the same folder. So the each page can additionally include its own resources.
    Typical MVC file structure has Views folder and, probably, should be protected, so we cannot put per-page resources there. So all of them should go into other folder. For example, Resources.

    But this not nice to develop because of we'll have Views/Home/Index.aspx file with Resources/Home/Index.css, Resources/Home/Index.js etc.

     
    So my questions

    Q1) What is the best way to reference static content from dynamic page?

    1. Use Url.Content.
    2. <a runat="server" href="~/Content/SomeResource" />.
    3. Application helper like App.Content.Link("SomeResource"). My preference.
    4. What else?

     

    Q2) What is the best way to reference dynamic content from static?

    1. Follow convention and never change routing (eg: "/Users/Online/GetTop")
    2. Follow convention but create alias routes for such references (eg: create alias "/Dynamic/Users/Online/GetTop" for "/Users/Online/GetTop").
      So while the page routes can be changed, links to dynamic content will be the same. For now my preference.
    3. Handle static content by ASP.NET and parse it (eg: write static content like this new Ajax.Request("<%#Url.Reference<UsersController>(x=>xGetTopUsersOnline)%>"). Too bloated.
    4. What else?

     

    Q3) What is the best way to include per-page resources (Page.aspx should include number of Page.css, Page.js etc) from views?

    1. Put all per-page resources into a separate folder (Content/Pages or so) folder and follow a convention.
    2. Put per-page resources under Views/Home folder and reference them like so Url.Content("Views/Home/Index/Index.js"). Not good if Views folder should be private.
    3. Follow a convention (per-page resources are located under Resources folder). And generate link like so "Resources/Home/Index/Index.js" using Url.Reference("index.js"). It will take current controller and  view name (not action - many actions can render the same view) and will concat it to "Resources/{Controller}/{ViewPage}/{File}".
    4. What else?


    What do you think about it?

    Cheers,
    Dmitriy.

    Filed under: ,
  • Re: Static content linking

    05-12-2008, 10:22 AM
    • Loading...
    • superevanc
    • Joined on 02-15-2006, 9:11 PM
    • Posts 16

    Hey Dmitriy,

    Q1) What is the best way to reference static content from dynamic page?

    I tend to put all my static content under a directory /assets.  So I will have /assets/images and /assets/styles and so on.  I always reference these asset files from the root and never use the ~ operator.

    <img src="/assets/images/myimage.jpg" />

    Q2) What is the best way to reference dynamic content from static?

    Not really sure what you are trying to do here, I rarely see this situation.  Your static content that may reference dynamic data probably should not be getting processed by the asp.net runtime.  So if you have a static html page I think your solution is going to have to be very specific to your situation.

    Q3) What is the best way to include per-page resources (Page.aspx should include number of Page.css, Page.js etc) from views?

    Now, best is very subjective in programming and this questions doesn't have one best practice answer.  If each page has few unique resources you would be better off shoving them into one css or js file so that the browser only has to download one resource when they hit your site.  The other hits to your pages will then have those resources cached on the browser making everything better for both the server and client.

    If you have a page that has a lot of heavy resources compared to other pages on your site and this page is not accessed frequently then you would probably be better off having per-page resources for that page.  Whenever I run into this situation I tend to separate them as follows /assets/reallyheavypage/script.js
     

  • Re: Static content linking

    05-12-2008, 9:22 PM
    • Loading...
    • nagir
    • Joined on 01-09-2006, 7:01 PM
    • Australia
    • Posts 87

    Hi,

     

    superevanc:

    I always reference these asset files from the root and never use the ~ operator.

    <img src="/assets/images/myimage.jpg" />


    But this way you always have to assume the site is hosted in the root directory. It is not acceptable for me.

    superevanc:
    reference dynamic content from static?

    Not really sure what you are trying to do here, I rarely see this situation. 

    It's very common. Typical example: JavaScript (in a separate static file) that performs Ajax requests.

    superevanc:
    Whenever I run into this situation I tend to separate them as follows /assets/reallyheavypage/script.js

    So you generally create folder in your assets per page to host there everything related to that page. What do you think about putting those files into Views folder?


    Cheers,
    Dmitriy.

  • Re: Static content linking

    05-13-2008, 1:51 PM
    • Loading...
    • superevanc
    • Joined on 02-15-2006, 9:11 PM
    • Posts 16

    Always so hard to answer best way questions.  Programming is so problem specific :)

    nagir:

    But this way you always have to assume the site is hosted in the root directory. It is not acceptable for me.

    A very valid point.  I wouldn't say you have to assume it's hosted in the root directory though, just that you have to always be sure of the root path.  I'm fortunate to be able to be sure of this on most projects.  I find that it makes life much easier when this is the case.

    nagir:

    It's very common. Typical example: JavaScript (in a separate static file) that performs Ajax requests.

    Ah OK, I see.  If you are very concerned about the urls changing you could construct a settings object that gets initialized on the dynamic page using the urls you need.

    nagir:

    So you generally create folder in your assets per page to host there everything related to that page. What do you think about putting those files into Views folder?

    I never really thought about it actually.  I could see that causing a problem for me though since it would make it more difficult to separate those assets for scaling purposes.  The reason I put all my static content under an /assets folder is that it makes it very easy to do things like map http://assets1.mysite.com and http://assets2.mysite.com to this folder.  This allows for connection optimizations on the web browser as well as an easy transition when you need to bring in a Content Distribution Network.  Also it allows me to specify long term expires dates and other caching type headers for all the static content in one easy place.

    Regards.

     

  • Re: Static content linking

    05-13-2008, 7:13 PM
    • Loading...
    • nagir
    • Joined on 01-09-2006, 7:01 PM
    • Australia
    • Posts 87

    Hi, 

    superevanc:
    The reason I put all my static content under an /assets folder is that it makes it very easy to do things like map http://assets1.mysite.com and http://assets2.mysite.com to this folder. 

    Ok. I see your point. Just keep static content separated at all.
    BTW, with this approach (assets1, assets2...) you can have problems with JavaScript because of Same origin policy.

    Cheers,
    Dmitriy.
     

Page 1 of 1 (5 items)