Re: Jquery Ajax method call with asp.net static webmethods - ASP.NET Discussion Boards

Cool, thank you!!

Hi,

Here's what I understand how Jquery Ajax method call works with asp.net static web methods.

First the page object is created on server to serve the page when you try to load a webpage. But when you make an ajax call from Jquery ajax method you actually point to a static web method which cannot access any of the page controls as it cannot create an instance of the page in itself.

So can I put it this way? - These static web methods cannot access the page's controls or their view state hence the danger of multiple requests and concurrency does not arise.

You call a static web method which means it does not have an associated object making it stateless(why do they use the term stateless?), which there by makes it work like a service which takes data, processes it, and returns something but does not keep anything to itself. Also you can choose to change the state of the controls present on the webpage by getting data in this manner and using JavaScript as there is no view state involved.

We can therefore presume that this workflow will not cause any concurrent access problems even though it uses static methods and fields.

Is there any flaw in my understanding?.

modified 9-Nov-15 12:36pm.

Yes, there is a pretty serious flaw.

If you have a static method on a non-static object, an instance WILL be created by the ASP.NET host in order to process the request, therefore any constructor logic will fire. The static signifies that the method (or field, or object) will only be created once, and all calls made by the application for that static element will point to the same memory address space.

Because of this, the static element is unaware of INSTANCE methods, properties, and fields, but can work with other static elements. This means that a static elements is not inherently stateless, and this is where concepts like thread safety come into play. If a static method calls un-managed code, you also run the risk of concurrency issues on the un-managed elements.

Generally, the best stateless methodologies follow non-static instance methods, because the class handling the HTTP request will instantiate, perform its work, and be disposed. By leveraging statics, you introduce state to an object.

Stateless is a reference to object State graphs, where operations that occurred before can affect operations that come later.

Nathan Minier wrote:
If you have a static method on a non-static object, an instance WILL be created by the ASP.NET host in order to process the request, therefore any constructor logic will fire. The static signifies that the method (or field, or object) will only be created once, and all calls made by the application for that static element will point to the same memory address space.

An instance won't be created. If you call a static method on a type that has not yet been loaded into the app domain then the type is loaded. If that type has a static constructor the static constructor will be called. Once a type is loaded into the app domain it will remain, so the next time you call a static method on that type the static constructor is not called again as the type hasn't been loaded as it has been previously loaded.

Talking specifically about the context of the problem, if you have a page that serves controls etc, and also houses static methods you call via ajax then the type will already have been loaded in order to serve the page (and it is at this point the static constructor is called, and then the non-static constructors for the specific instance of this page) so your static methods will already be available in the app domain, so calling them won't even trigger the static constructor.

Nathan Minier wrote:
By leveraging statics, you introduce state to an object.

I disagree. If your static methods use static variables then you are creating "state" (albeit "global" state), but using static methods on their own does not introduce what would be considered state in this context.

I've done a bit of looking around, and while I see some hearsay about the WebService HTTP Handler using per-request instantiation, I cannot find any specific documentation from MSDN. I've not tested it, so I'm willing to cede that it could work differently than every other Microsoft HTTP Handler.

And as far as hard-and-fast rules go, I'll happily agree to disagree about statics and state. I've almost never seen a coder that leaned on static methods not start doing the same with fields for shortcuts, though.

Sorry, I have to agree with F-ES Sitecore: Accessing a static member does not create an instance of the class, and using static methods does not introduce state to an object.

"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer

No need for a sorry, if I'm wrong about the way that the Web Service HTTP Handler works then I accept that. The other ASP.NET handlers will create an object, however, whether you're calling a static method or not. HttpContext, Request, and Response objects are all instance members.

The "static methods lead to state" comment has more to do with philosophy the literal implementation. I've seen (and done) it enough times to know, creating static methods leads to creating static fields. It's not completely inevitable, but in the web application world it's pretty close to being so.

ganesh.dks wrote:
These static web methods cannot access the page's controls or their view state hence the danger of multiple requests and concurrency does not arise.

Unless your static methods then use static variables. As long as your static methods only use local variables you'll be ok.

ganesh.dks wrote:
You call a static web method which means it does not have an associated object making it stateless(why do they use the term stateless?), which there by makes it work like a service which takes data, processes it, and returns something but does not keep anything to itself.

It's called stateless because it takes data, processes it, and returns something but does not keep anything to itself Smile | :)

ganesh.dks wrote:
Also you can choose to change the state of the controls present on the webpage by getting data in this manner and using JavaScript

If I had to be really pedantic I would point out that "controls" (as in server-controls like asp:Textbox etc) only exist while the page is being processed in the asp.net page lifecycle. Once the page has finished being created it is converted to html and sent to the client to display. At this point you simply have html and html elements, your controls no longer exist. When you submit the form asp.net uses view state to re-create those controls, re-create the html, server that html and again your controls are destroyed, they no longer exist.

If you call ajax methods and update the DOM via javascript all you are doing is amending the DOM, the client html elements. You are not changing the state of the controls as that state is held in the view state, and that is what your controls get re-created\deserialized from. Any changes you make to the "state" of your controls via js (let's say you add an option to a select element, or change the colour of some text) are unknown to asp.net and when you submit your form the controls will be re-created from the viewstate (which you haven't amended) and your amendments will be lost.

I have encountered a problem of updating dock panels on client side ( browser ). After time interval elapses, I have to send callback to update the contents of dock panel.

Each and every dock panel can have own respective time interval that can be set/reset by the user by interacting it's settings module. Thus we can have something like

dock panel_a : update after 10s

dock panel_b : update after 5s

dock panel_c : update after 15s

...............................

later on user might can change all the timers and these module might update totally on different intervals. I might be ended up having 100's of dock panels and correspondingly 70's would update their contents and 30 might never update Or 30 would update and 70 would be set to Never update.

What would be right implementation??

Should I write complete server side functionality ( in this case, I would write delegates or complete asynchronous implementation for updating all modules available on client side )??

Should I maintain a list of available panels at client side and need to access that list for sending callback once the time interval elapse for specific dock panel? If so, I would definitely need a parent timer available on client browser window which would count the seconds and on completion of seconds, it will match and refer the previously maintain list. If so,

List might contain 50 panels corresponding 50 timer objects.. Would that be fine?

Note: I am more in a favour of implementing server side code ( delegates and asynchronous ) because my server side better knows how many dock panels rendered on screen and for each dock panel it can maintain thread to update dock panel on client side.

what should be the right way?

Regards

Usman

You could include SignalR in your application to push updates to currently connected users. Alternatively you could use JavaScript timers to pull updates. Considering that you'll need to write a bit of JS to coordinate where the updates are targeting, that would be my route.

You should just need 1 timer, though, and attach the panel updates as events to a periodic method. Multiple timers that all do the same thing is just a waste of resources.

I understand Views, but as my project gets bigger and to stay organized, I wanted to create views within views.

So If I have a view called Admin or
http://website.com/Admin
I wanted to create a folder under it
http://website.com/Admin/Management

So I googled around the interwebs, and I guess I can't get the nomenclature to find the answer.
I can't see having a huge backend in MVC and making a huge model and controller in Admin.

modified 6-Nov-15 15:17pm.

A view within a view is called a Partial View. If you are referring to how you physically store the views on disc, then if you don't want to follow the naming convention of controller\action.cshtml then when you return a View from a controller you'll need to explicitly specify the path of the view you are returning.

http://stackoverflow.com/questions/879852/display-a-view-from-another-controller-in-asp-net-mvc[^]

I was referring to the latter. But you gave me a nudge in the right direction. I'll look at the route config.

For a C# WPF position I got asked

"You have an MVC unit- How do you get around dependencies?"

I'm not looking for the answer.. I don't even understand the question.

What are they asking here?

Also, why would this have anything to do with WPF??

modified 3-Nov-15 13:30pm.

And why have you posted this in the ASP.NET forum?

Last time I checked, MVC is part of ASP.net.

MVC is a design pattern.

zephaneas wrote:
What are they asking here?

I don't understand either. Maybe they meant "unit test" rather than "unit"? Or maybe they meant you were re-using code from an MVC project in your WPF project. There is no harm is asking them to explain what they mean.

I want to do a parody album management ASP.NET application, you can upload pictures, display, preview.
Give me an idea seeking seniors and help

What have you tried?
Where are you stuck?
What help do you need?

Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...

I have not good idea for this function,I need a detailed plan.

You mean it's your homework and you don't know how to do it, or what?

Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...

Member 11883266 wrote:
I need a detailed plan.

That is called "Research, analysis and design", and is what you do before you start coding.

yes indeed ,I am very stupid,I don't want to use plugin to upload images,feeling very complex use plug-ins,I want to try do this use pure code,can you help me

Nobody is calling you stupid!

But...we do not do your homework: it is set for a reason. It is there so that you think about what you have been told, and try to understand it. It is also there so that your tutor can identify areas where you are weak, and focus more attention on remedial action.
And working out what you need to do, and what you need to learn in order to do that is part of the task.

Try it yourself, you may find it is not as difficult as you think!

If you meet a specific problem, then please ask about that and we will do our best to help. But we aren't going to do it all for you!

Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...