Tech Off Thread

4 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Why do this on the server? (ASP.Net)

Back to Forum: Tech Off
  • User profile image
    WayneB

    I'm wondering why code like this is continually recommended by ASP.Net developers:

    Me.BtnDelete.Attributes.Add("onclick", _
                       "return confirm('Are you sure you want to delete?');")

    (http://aspnet.4guysfromrolla.com/articles/021104-1.aspx)

    It seems to me that the ASP.Net team wants me to do everything on the server.  There is virtually no support for client-sided scripting in VS.Net (I.E. when I drop a button on a WebForms designer and double-click on it, I get a server-sided event handler code block, also there is no code navigation support except for the lame document outline)

    Another example...disabling a button.  Why should all of the form data, (viewstate whatever you want to call it) be shuttled back to the server and make my browser reload (not pretty) when all I have to do in client-side script is this or something similar:

    document.getElementById("btnDelete").disabled = true;

    Granted, it's a pain to detect which browser is being used, if scripting is turned on, etc. but I only write private web applications for IE5.5+.

    Personally, the only reason I need the server-side is to validate data and shuttle data in and out of the DB (either directly or through business objects).  All of my UI logic is handled on the client and RDS makes it easy to get a bindable recordset from the server.

    I realize I can still code "my way" with VS.Net, but they haven't made it any easier. There was so much work done making IE the most robust developers tool, why is it being dropped for doing everything on the server?

  • User profile image
    GooberDLX

    WayneB wrote:

    I'm wondering why code like this is continually recommended by ASP.Net developers:

    Me.BtnDelete.Attributes.Add("onclick", _
                       "return confirm('Are you sure you want to delete?');")

    (http://aspnet.4guysfromrolla.com/articles/021104-1.aspx)



    Technically, the only thing happening at server side, by that statement, is that when the HTML is rendered.. it will add the onclick="return confirm('Are you sure you want to delete?');" to your button attribute list

    This is definitely NOT a server side event.. its javascript!

    Though I do see where you are coming from.. I guess it can be explained by the event-driven nature of ASP.Net .. But as far as using java script along side of ASP.Net .. its perfectly simple and also encouraged so that you can fine tune. Nothing stops you from writing in javascript to the ASPX page? And if you don't want it posting back, then make sure your AutoPostBack property is set to False for your control...

    Jake

  • User profile image
    WayneB

    Why not just put it right in the HTML instead of making the server do anything at all, like this:

    <button onclick="return confirm('...');"/>

    My main complaint is that I like to do as much as possible on the client and there's never been anything to really accelerate development there.  I would really like the drop-down lists of objects/events that are available for server controls.

    I would really, really like it if the events of Element Behaviors were included as well.

    However, aren't HTC's going the way of the dodo now?

  • User profile image
    GooberDLX

    I agree and disagree with what you say... IMHO, I don't think that you should do as much as you can on the client side in an ASP.Net environment. Granted todays computers are getting more powerful as we speak, but for client satisfaction, you have to draw a line between what could slow the client's system down and what you can afford to do server-side to ensure client satisfaction..

    But I think it is nice to have interaction events be taken care of client side.. The main reason JavaScript is the first way to go is because its the only somewhat standard method of a browser being event driven and interacting with the content on the site..

    Yeah, I dont see HTC's being any more in use.. The day will come when we'll see a browser independant, interaction framework .. that is the standard.. talk about taking a non-interactive HTML session to a whole new level Smiley

    IMHO,
    Jake

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.