DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 7 of 7

Thread: Best Practices: Linking to another page

  1. #1
    Michael Guest

    Best Practices: Linking to another page


    I'm looking for some other views on the best way to get from one .aspx to
    the next. In my application there are several places where the user will
    encounter a "Continue" button. The button doesn't necessarily do anything
    other than take the user to the next page. It seems there are several ways
    to go about it... but which one is the "best"?

    1)A simple html button with some javascript

    2)An ASP sever control button with a redirect, or transfer in the on-click
    event

    3)An ASP link button

    In classic ASP I would have chosen option one, Option 3 seems the best in
    .net, however I don't like the look of the link button.

    Any comments...?


  2. #2
    Itai Raz Guest

    Re: Best Practices: Linking to another page

    Hi Michael,

    We have had this question in mind too at some point. Personally, I'm not a
    big fan of such "best practices", and I'm more into doing whatever seems
    right for what you are creating. We're talking about something that will
    probably not have much effect on your system. I would just go with what's
    good at the moment.

    check out my comments in between your text about the individual options.
    Hope it will help.

    --itai


    "Michael" <vb.@127.0.0.1> wrote in message
    news:3e0b3e82$1@tnews.web.devx.com...
    >
    > I'm looking for some other views on the best way to get from one .aspx to
    > the next. In my application there are several places where the user will
    > encounter a "Continue" button. The button doesn't necessarily do anything
    > other than take the user to the next page. It seems there are several

    ways
    > to go about it... but which one is the "best"?
    >
    > 1)A simple html button with some javascript

    It works. It's kind of breaking the ASP.Net model, which is putting more
    emphasis on the server side, but as I mentioned - who cares what M$ had in
    mind.... You can always change it if the need arises. The advantage of this
    method is that it doesn't put any load on your server. Disadvantage is that
    if you're trying to do more than just move to a different page, you may need
    to do some loops in the air to get data that is otherwise (if you use server
    side) readily available.

    >
    > 2)An ASP sever control button with a redirect, or transfer in the on-click
    > event

    That's the way god (Bill) intended, I think. Again, if you're programming,
    say, an intranet application that will not have a lot of load on it, you can
    choose this method even for the simplest transfer. It will give you most
    control over what's going on. If you're writing a robust server application
    for millions of users, and you don't mind using JS (assuming most browsers
    support it), then you probably don't want to have your server occupied doing
    redirect for the users.
    >
    > 3)An ASP link button
    >
    > In classic ASP I would have chosen option one, Option 3 seems the best in
    > net, however I don't like the look of the link button.

    Why is it the best, if you don't like the way it looks? If it's not what you
    want, then it's not the best.... Personally, I wouldn't take that one.
    >
    > Any comments...?

    Yeah, they're all up there.
    >




  3. #3
    Michael Guest

    Re: Best Practices: Linking to another page


    I decided on the redirect method... But when it runs I get the following exception:

    "System.Threading.ThreadAbortException"

    Which I can can trap and ignore (the redirect still happens), but it seems
    kind of sloppy...


    "Itai Raz" <notreadingthis@hotmail.com> wrote:
    >> 2)An ASP sever control button with a redirect, or transfer in the on-click
    >> event

    >That's the way god (Bill) intended, I think. Again, if you're programming,
    >say, an intranet application that will not have a lot of load on it, you

    can
    >choose this method even for the simplest transfer. It will give you most
    >control over what's going on. If you're writing a robust server application
    >for millions of users, and you don't mind using JS (assuming most browsers
    >support it), then you probably don't want to have your server occupied doing
    >redirect for the users.
    >>



  4. #4
    Itai Raz Guest

    Re: Best Practices: Linking to another page

    hmm. Not sure. Are you maybe sending data to the client before you do the
    redirect?

    How are you doing the redirect? Using Response.Redirect? Server.Transfer? If
    you're using Server.Transfer, I don't see why you would get such error, but
    maybe it depends on what you're doing prior to your redirect command.

    --itai


    "Michael" <modeen@acitel.com> wrote in message
    news:3e14afc4$1@tnews.web.devx.com...
    >
    > I decided on the redirect method... But when it runs I get the following

    exception:
    >
    > "System.Threading.ThreadAbortException"
    >
    > Which I can can trap and ignore (the redirect still happens), but it seems
    > kind of sloppy...
    >
    >
    > "Itai Raz" <notreadingthis@hotmail.com> wrote:
    > >> 2)An ASP sever control button with a redirect, or transfer in the

    on-click
    > >> event

    > >That's the way god (Bill) intended, I think. Again, if you're

    programming,
    > >say, an intranet application that will not have a lot of load on it, you

    > can
    > >choose this method even for the simplest transfer. It will give you most
    > >control over what's going on. If you're writing a robust server

    application
    > >for millions of users, and you don't mind using JS (assuming most

    browsers
    > >support it), then you probably don't want to have your server occupied

    doing
    > >redirect for the users.
    > >>

    >




  5. #5
    Michael Guest

    Re: Best Practices: Linking to another page


    Thanks for the help!

    I'm setting a couple of properties on an object that's held in a session
    variable. The values come from from a listbox. I get the same error with
    server.transfer.

    In the click event:

    mAct = CType(Session("Interaction"), Interaction)

    If lbCalltypes.SelectedIndex > 0 Then
    mAct.FinishCode = lbCalltypes.SelectedItem.Value.ToString
    mAct.Calltype = lbCalltypes.SelectedItem.Text.ToString
    Response.Redirect("ConfirmCalltype.aspx")
    End If


    "Itai Raz" <notreadingthis@hotmail.com> wrote:
    >hmm. Not sure. Are you maybe sending data to the client before you do the
    >redirect?
    >
    >How are you doing the redirect? Using Response.Redirect? Server.Transfer?

    If
    >you're using Server.Transfer, I don't see why you would get such error,

    but
    >maybe it depends on what you're doing prior to your redirect command.
    >
    >--itai
    >
    >
    >"Michael" <modeen@acitel.com> wrote in message
    >news:3e14afc4$1@tnews.web.devx.com...
    >>
    >> I decided on the redirect method... But when it runs I get the following

    >exception:
    >>
    >> "System.Threading.ThreadAbortException"
    >>
    >> Which I can can trap and ignore (the redirect still happens), but it seems
    >> kind of sloppy...
    >>
    >>
    >> "Itai Raz" <notreadingthis@hotmail.com> wrote:
    >> >> 2)An ASP sever control button with a redirect, or transfer in the

    >on-click
    >> >> event
    >> >That's the way god (Bill) intended, I think. Again, if you're

    >programming,
    >> >say, an intranet application that will not have a lot of load on it,

    you
    >> can
    >> >choose this method even for the simplest transfer. It will give you most
    >> >control over what's going on. If you're writing a robust server

    >application
    >> >for millions of users, and you don't mind using JS (assuming most

    >browsers
    >> >support it), then you probably don't want to have your server occupied

    >doing
    >> >redirect for the users.
    >> >>

    >>

    >
    >



  6. #6
    Sekar Guest

    Re: Best Practices: Linking to another page


    Some tips from MS to prevent System.Threading.ThreadAbortException

    http://support.microsoft.com/default...b;en-us;312629

    -S



    "Itai Raz" <notreadingthis@hotmail.com> wrote:
    >hmm. Not sure. Are you maybe sending data to the client before you do the
    >redirect?
    >
    >How are you doing the redirect? Using Response.Redirect? Server.Transfer?

    If
    >you're using Server.Transfer, I don't see why you would get such error,

    but
    >maybe it depends on what you're doing prior to your redirect command.
    >
    >--itai
    >
    >
    >"Michael" <modeen@acitel.com> wrote in message
    >news:3e14afc4$1@tnews.web.devx.com...
    >>
    >> I decided on the redirect method... But when it runs I get the following

    >exception:
    >>
    >> "System.Threading.ThreadAbortException"
    >>
    >> Which I can can trap and ignore (the redirect still happens), but it seems
    >> kind of sloppy...
    >>
    >>
    >> "Itai Raz" <notreadingthis@hotmail.com> wrote:
    >> >> 2)An ASP sever control button with a redirect, or transfer in the

    >on-click
    >> >> event
    >> >That's the way god (Bill) intended, I think. Again, if you're

    >programming,
    >> >say, an intranet application that will not have a lot of load on it,

    you
    >> can
    >> >choose this method even for the simplest transfer. It will give you most
    >> >control over what's going on. If you're writing a robust server

    >application
    >> >for millions of users, and you don't mind using JS (assuming most

    >browsers
    >> >support it), then you probably don't want to have your server occupied

    >doing
    >> >redirect for the users.
    >> >>

    >>

    >
    >



  7. #7
    Michael Guest

    Re: Best Practices: Linking to another page



    Wonderful...! Thanks...

    "Sekar" <sekar@ieee.org> wrote:
    >
    >Some tips from MS to prevent System.Threading.ThreadAbortException
    >
    >http://support.microsoft.com/default...b;en-us;312629
    >
    >-S
    >
    >
    >
    >"Itai Raz" <notreadingthis@hotmail.com> wrote:
    >>hmm. Not sure. Are you maybe sending data to the client before you do the
    >>redirect?
    >>
    >>How are you doing the redirect? Using Response.Redirect? Server.Transfer?

    >If
    >>you're using Server.Transfer, I don't see why you would get such error,

    >but
    >>maybe it depends on what you're doing prior to your redirect command.
    >>
    >>--itai
    >>
    >>
    >>"Michael" <modeen@acitel.com> wrote in message
    >>news:3e14afc4$1@tnews.web.devx.com...
    >>>
    >>> I decided on the redirect method... But when it runs I get the following

    >>exception:
    >>>
    >>> "System.Threading.ThreadAbortException"
    >>>
    >>> Which I can can trap and ignore (the redirect still happens), but it

    seems
    >>> kind of sloppy...
    >>>
    >>>
    >>> "Itai Raz" <notreadingthis@hotmail.com> wrote:
    >>> >> 2)An ASP sever control button with a redirect, or transfer in the

    >>on-click
    >>> >> event
    >>> >That's the way god (Bill) intended, I think. Again, if you're

    >>programming,
    >>> >say, an intranet application that will not have a lot of load on it,

    >you
    >>> can
    >>> >choose this method even for the simplest transfer. It will give you

    most
    >>> >control over what's going on. If you're writing a robust server

    >>application
    >>> >for millions of users, and you don't mind using JS (assuming most

    >>browsers
    >>> >support it), then you probably don't want to have your server occupied

    >>doing
    >>> >redirect for the users.
    >>> >>
    >>>

    >>
    >>

    >



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center