Call WebMethod declared on a DIFFERENT aspx page?

I'd like to expose a WebMethod on an ASPX page and then invoke it from my Atlas page:

<atlas:ScriptManagerrunat="server"ID="scriptManager">

<services>

<atlas:servicereferencepath="MyAspxBasedService.aspx"type="text/javascript"/>

</services>

</atlas:ScriptManager>

Then invoke it. The reason is that I want the full ASPX processing to happen. In short, I want to declaratively create controls on the ASPX page, then render partial pieces of them to be returned back to the Atlas client.

Any help?

Tad

Just as I sent, I noticed that you wanted to call a page method on adifferent page, so clearly PageMethods.YourMethodName() won't work.

Calling a method on a different page is not supported. I'm not convinced that this is desirable; when you call a method on the current page, the point is that the server page gets populated with all the data from the browser, and that your method can make use of it. But if it's a different page, it can only have its clean original state, which seems a lot less useful.

David

Hi Tad,

You don't need to use any servicereference to call a method that's on the page itself. Just mark the method with a [WebMethod] attribute, and call it using the name PageMethods.YourMethodName(...).

David

Thanks David.

I've got a flyout asp:Menu control on my site that is 3 levels deep, which bulks up the page size and is pig slow. I thought about seeing if I could get the same benefits of the control by making it populate on demand. So, my ASPX call will pass a parameter indicating which branch of my menu I need to render (from my database). I would use the menu control to programmatically build the branch and render the html which I'd return from my webservice call. (of course I'd cache it too).

The nice thing about the ASPX page is that I can declaratively define the menu properties and templates.

I suppose I could make an XmlHttpRequest directly to the ASPX and pass query string params, but that seems soooooo YESTERDAY!

I'm just foolin' around. Any ideas before I go off and just build my own lightweight flyout control?

Tad

Why not use a Web Service that provides your site navigation menu data that takes, as input, information indicating the current branch that the page is on? Atlas is definitely designed for dealing with that type of scenario, and the 'pig slow' effect can be mitigated by having bits of your menu populated dynamically asynchronously using the Web Service invocation.

Obviously if you're tied to only using an ASPx page, then thats that...but one of the first things I did with Atlas was whip out a dynamically-generated site navigator that was powered by a Web Service. I was really impressed with it.

I wouldn't attempt that myself. Plus, I don't think a flyout menu is the right control for on-demand population (which is exactly why we didn't include the feature in the first place). Imagine what will hapen if the user flies his mouse cursor over the menu (which he'll necessarily do unvoluntarily): tens of requests sent to the server at the same time. Ugly.

Developing a lighter menu with fewer features but with focus on CSS without inline styles is probably a much better option. I was thinking of doing that when I have some time (which probably means not in the next few weeks).

Sure, that's a good point, and even without using a web service and dynamic population, reducing the depth of the menu and starting at the current hierarchy level can help considerably.

A combination of a menu and a SiteMapPath can give a good navigation UI without going too fancy.

About what you describe, the thing is that the menu does not support populate on demand. A treeView would do the trick, but that may not be the UI you want (although the TreeView appearance can be brought close to that of a menu with the exception of the fly-outs).