Back to Questions
3.4k
views16
comments
Routing problem with MarkerClusterer
websharpersiteletroutingmarkerclusterer

Hi,
In our web we use google maps with MarkerClusterer ( [link:fpish.net] ) on home page. I found out, that when we change url from

1

http://localhost:56300/Home

to

1

http://localhost:56300/Home/

the MarkerClusterer stops work.

-This is simplified observation of our change of routing of our home page:

1
2
3
4
5
6
7
8
9

type Action =
    | Home of string
    ...

let home = 
     Sitelet.Infer <| fun action ->
         match action with
         | Action.Home s -> Pages.HomePage s
         | _ -> Content.ServerError

instead of simple:

1
2
3
4
5

type Action =
    | Home
    ...

let home = Sitelet.Content "/Home" Action.Home Pages.HomePage

So I conclude that the MarkerClusterer has some problem with changed routing, but haven't managed to work around it somehow.
Could someone help me with that, please?

Thank you,
Tomas

P.S. I can send sample test project where this issue can be observed.

.

Not sure in what way the MarkerClusterer would be effected by such change in URL routing, but feel free to send along your project so we can investigate.

By on 8/8/2014 5:23 PM ()

Hi, Although I sent it by email, here is a link to test project, possibly for others:

[link:onedrive.live.com]

BTW, Is there any progress with it?

By on 8/14/2014 5:10 AM ()

Your attachment uses an older WebSharper project layout and has a number of paths that are invalid on machines other than yours. If you could recreate it using the latest WebSharper and send that, it would be appreciated.

In the meantime, does your page rely on relative links? When your page's URL changes depth (such as moving from /abc to /abc/xyz, it will break relatively links you may have on it. This could cause what you are experiencing, although it's hard to tell without a running example. Perhaps you could just send a URL to a live deployment?

Thanks.

By on 9/4/2014 5:10 PM ()

Hi Adam,

I am not sure if I can install new version of WS on my production machine. Probably I don't have permission on it (compile our commercial project with it) and it could interfere with my older project. Or is it OK? If it is OK I will recreate my test project and send to you.

My attachment is only slightly modified version of "Sample Web Application (sitelets)" project from VisualStudio where is only inserted MarkerClusterer to the home page, so I don't think there is a problem with relative links. And it is not a lot of work to reproduce it in newer version of WS.

In the meantime here is the URL to live deployment: [link:ns.codoma.cz]

-you can see that error in the console in the firebug for instance.

Thank you.

By on 9/5/2014 6:56 AM ()

I see the issue. The dependency for the MarkerClusterer library is included as

Scripts/markerclusterer_compiled.js

instead of

/MarkerTest/Scripts/markerclusterer_compiled.js

Just to be sure, how is this dependency declared on the extension you are compiling with?

By on 9/6/2014 5:08 PM ()

It is declared in Main.fs in IntelliFactory.WebSharper.MarkerClusterer as shown in:
[link:fpish.net]

So how to set it to be resilient to URL depth changes?

By on 9/8/2014 12:49 AM ()

Here are some clarifications about why it didn't work and what is fixed in the NuGet package.

The scheme to determine the url to include for a resource declared as Resource "name" "somePath.js" is as follows:

  1. If the assembly contains an embedded resource file named somePath.js, then this file is extracted to (website root)/Scripts/WebSharper/somePath.js, and a corresponding URL is generated and used.
  2. If there is no such embedded resource file, then somePath is used as is as the source path to include. This means that somePath should be an absolute path (such as /some/path.js or http:// someSite.com/some/path.js), or the problem that you faced will occur.

The NuGet package uses an embedded resource, so the js file will be automatically extracted as /Scripts/WebSharper/markerclusterer_compiled.js.

By on 9/15/2014 6:34 AM ()

We just published MarkerClusterer to NuGet under the name WebSharper.Google.Maps.MarkerClusterer. Can you try to use that and confirm that the reference is added correctly?

By on 9/15/2014 5:44 AM ()

It doesn't compile now, it gives this error:

C:\Users\kanovsky\Documents\Visual Studio 11\Projects\MarkerTest2\packages\WebSharper.2.5.125.62\build\WebSharper.targets(55,5): error : Failed to deserialize metadata for: IntelliFactory.Formlet, Version=2.4.0.0, Culture=neutral, PublicKeyToken=451ee5fa653b377d

I think the problem is now that your package has dependency on WebSharper 2.5.125.62 and I use WebSharper 2.4.
Maybe I will have to upgrade to newer version of WS, but are there any breaking changes? Will I be able to compile my solution?
What about licensing, although by this [link:websharper.com] it looks it should be ok to use version 2.5 after having licence for 2.4.

Or can I fix my old version of MarkerClusterer somehow?

By on 9/15/2014 7:51 AM ()

All current extensions target the latest WebSharper, so yes, you will need to upgrade to 2.5 to benefit from this package. Licensing-wise, since you have a 2.4 license you should be covered (but support requires a yearly renewal).

By on 9/15/2014 8:08 AM ()

Ok, I am now on a journey to upgrade to WS 2.5. I have recreated the whole solution, supplied all required nuget references and ended up with this:

C:\Vyvoj\Web\AspoBooking\packages\WebSharper.2.5.125.62\build\WebSharper.targets(55,5): error : Failed to deserialize metadata for: IntelliFactory.WebSharper.Formlet.JQueryUI, Version=2.4.0.0, Culture=neutral, PublicKeyToken=dcd983dec8f76a71

So now I already know that this is older version, not compatible with WS 2.5, right?
I wanted to donwload newer version from [link:www.websharper.com] where it is stated that need license, so I logged in, but I dont't see my license there, although we have one.

So what should I do now?

Thank you

By on 9/16/2014 8:06 AM ()

The original 2.4 license granted you WebSharper 2.4 and minor updates, and a handful of extensions. Since then, we switched to a simpler licensing model and introduced many new extensions and tools.

The new support site (which gives access to extensions, updates to extensions, and updates to WebSharper) is coded to interpret old licenses as: "2.4 licenses cover WebSharper 2.x, but not updates issued to extensions targeting 2.5+."

This goes back to the combination of reasons that 1) we now have many more extensions than back with 2.4, 2) back then extensions were available via support URLs and now they are on a private Nuget feed, and 3) WebSharper itself is on the public Nuget feed. So all in all, and we had to draw the line somewhere what old license holders can access on the support site, and this line was to cover WebSharper but not the extensions, and worded the license update accordingly ("However, you will not benefit from any updates and bugfixes, as those require an ongoing license.").

This is rather unfortunate, and not something we can fix quickly. Updates to private and premium extensions are and have been for quite some time available to subscribers only.

You can do one of two things:

  1. Keep using WebSharper 2.4 with the 2.4 extensions you have (these older extensions are also available upon request, or can be obtained via public Nuget).

    • For new extensions such as WebSharper.Google.Maps.MarkerClusterer (a 2.5 extension), you can use WIG 2.4 with some extra care in your hand written extension. I know, this is what started this thread, but now on a second look, in theory, you could get away using WIG 2.4 with your own implementation of MarkerClusterer (as available here) by marking markerclusterer_compiled.js as an embedded resource. This should make the reference inlined correctly (but I didn't test it, and I might be wrong, sorry, but it's worth a try...)
  2. Renew your license to get access to all current private/premium extensions and their updates, including WebSharper.Formlet.JQueryUI.

To be as helpful as possible, I can also forward you the latest WebSharper.Formlet.JQueryUI extension package, since this seems to be the only extension update you require for your project.

Cheers,
Adam.

By on 9/16/2014 12:24 PM ()

Ok, I understand it.

In regard to setting the resources to right path I even realized (after Loïc's hints) that I can set the resource's path in web.config. Something like this:

<add key="IntelliFactory.WebSharper.MarkerClusterer.Resources.Js" value="http:/localhost:50674/Scripts/markerclusterer_compiled.js" />

So the MarkerClusterer is already resolved (even in WS 2.4).

But unfortunately there is other problem which I didn't notice earlier: The routing stops work for other Action than Home of string after my change as I showed In my first post above. It can be seen in that live deploy here: [link:ns.codoma.cz] - Other links give: 500.0 - Internal Error

So this was the other reason I started upgrading to WS 2.5, to we could further communicate other issues. In this regard I would appreciate if you could forward me that WebSharper.Formlet.JQueryUI package, so I could try it in the latest version of WS.

Thank you,
Tomas

By on 9/17/2014 1:14 AM ()

The reason why other pages throw an error 500 is because that's what the Content.ServerError you added in Sitelet.Infer does. It doesn't defer handling to the subsequent sitelets in the Sum; it just returns an error 500. There are two solutions:

  • The simplest is to just put your handler for Home in your main Sitelet.Infer (ie. use Pages.HomePage s as the return value for Action.Home), and to remove the separate one for Home.

  • If for some reason you absolutely need to define the sitelet for Home separately, you can use this code:

    1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

    let filterSitelet f (s: Sitelet<'a>) : Sitelet<'a> =
    {
        Controller = s.Controller
        Router =
            let partialRoute req =
                match s.Router.Route req with
                | Some a when f a -> Some a
                | _ -> None
            Router.New partialRoute s.Router.Link
    }

let home =
    Sitelet.Infer <| function
        | Action.Home s -> Pages.HomePage s
        | _ -> failwith "This will never be reached"
    |> filterSitelet (function
        | Action.Home _ -> true
        | _ -> false)

    What it does is tell WebSharper that if the request doesn't match Action.Home, then it doesn't want to handle it (instead of returning an error page), so it then gets passed on to the next sitelet in the Sum.

By on 12/2/2014 9:34 AM ()

Hi Loïc,

Thank you, it works now. First option is good enough, I could try it myself earlier, I was not very confident how it exactly works and it was based on earlier version of Sitelet project template, so it seemed correct how it was with separate home sitelet.

Cheers

By on 12/3/2014 2:44 AM ()

Sent, let me know in email how it goes.

By on 9/18/2014 3:08 AM ()

    Topic tags

    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