So, first of all -- we will probably fix the jQuery URL to point to https by default very soon (and check that all our extensions that point to a CDN do the same).

In the meantime, or if you still want to change the URL of a resource, you can use something like the following:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
module Context =

    let WithSettings (settings: seq<string * string>) (ctx: Context<'T>) : Context<'T> =
        let settings = dict settings
        let getSetting k =
            match settings.TryGetValue(k) with
            | true, x -> Some x
            | false, _ -> ctx.ResourceContext.GetSetting k
        { ctx with ResourceContext = { ctx.ResourceContext with GetSetting = getSetting } }

module Sitelet =

    let MapContext (f: Context<'T> -> Context<'T>) (sitelet: Sitelet<'T>) : Sitelet<'T> =
        { sitelet with
            Controller = { Handle = fun action ->
                Content.CustomContentAsync <| fun ctx ->
                    Content.ToResponse (sitelet.Controller.Handle action) (f ctx)
            }
        }

    let WithSettings (settings: seq<string * string>) (sitelet: Sitelet<'T>) : Sitelet<'T> =
        MapContext (Context.WithSettings settings) sitelet

// Example use:
[<Website>]
let Main =
    Application.MultiPage (fun ctx endpoint -> (* your application... *))
    |> Sitelet.WithSettings [
        "WebSharper.JQuery.Resources.JQuery", "https://code.jquery.com/jquery-1.11.0.min.js"
    ]

I'll discuss with the team whether it would also be a good idea to add the above functions to the library.

By on 3/18/2017 11:22 PM ()

This is a useful method for offline Websharper 4 HTML Site projects to force the JQuery dependency information. Is there a version that does not have to use Content.CustomContentAsync, which throws a depreciated warning?

By on 2/1/2018 2:10 PM ()

Thank you this looks very useful and should cleanly resolve the problem for now.

Just to note when you do fix the bug, please use "//blah/blah/somefile.ext". Which is to say, do not specify http: nor https: in front. This will ensure the browser uses the same scheme as the sitelet was loaded through. Which ensures the best possible compatibility.

By on 3/20/2017 10:54 AM ()

The inconvenient of "//url" without protocol is that it doesn't work when testing a single-page application from the filesystem (with "file://" protocol). In what situation would there be an incompatibility for an http site loading an https script?

By on 3/21/2017 10:58 AM ()
IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy
Built with WebSharper