Codebehind unaware of select box members populated via javascript

Discussion in 'ASP .Net' started by Allan M., Dec 8, 2003.

  1. Allan M.

    Allan M. Guest

    I have a series of select boxes that must be populated
    client side, because they interact with each other. The
    design specification calls for these boxes to be updated
    without having to make a roundtrip to the server.

    The codebehind seems to be unaware of select box members
    populated via javascript. So, I'm having to create my own
    state management solution, (i.e. rewriting the VIEWSTATE
    mechanism) to persist the state of these select boxes
    after a postback occurs.

    Is there an easier or better way to do this client-side?
    Note: Postback is not an option. That is the way the
    code was originally written, but end users were very
    unhappy with round trips to server.

    I need a way to be able to update controls using
    javascript and include the information in the viewstate
    whenever a postback occurs. Is this possible, or is
    mixing client-side and server-side form manipulation code
    just not done in ASP.NET?

    Thanks...
    Allan M., Dec 8, 2003
    #1
    1. Advertising

  2. Hi Allan,

    Although I haven't tried it, I'm wondering whether you could use a hidden
    server-side input box as a storage area for the populated data. Unlike the
    dropdownlist boxes, input boxes are meant to collect user data.

    Maybe you could store the values in some type of delimited string
    "blue|red|black" that you could parse on the postback and add to the
    listbox?

    I could be way off the mark here, but thought I would raise the possibility
    in case in sparks something else that suits.

    "Allan M." <> wrote in message
    news:05c401c3bde4$12e66cb0$...
    > I have a series of select boxes that must be populated
    > client side, because they interact with each other. The
    > design specification calls for these boxes to be updated
    > without having to make a roundtrip to the server.
    >
    > The codebehind seems to be unaware of select box members
    > populated via javascript. So, I'm having to create my own
    > state management solution, (i.e. rewriting the VIEWSTATE
    > mechanism) to persist the state of these select boxes
    > after a postback occurs.
    >
    > Is there an easier or better way to do this client-side?
    > Note: Postback is not an option. That is the way the
    > code was originally written, but end users were very
    > unhappy with round trips to server.
    >
    > I need a way to be able to update controls using
    > javascript and include the information in the viewstate
    > whenever a postback occurs. Is this possible, or is
    > mixing client-side and server-side form manipulation code
    > just not done in ASP.NET?
    >
    > Thanks...
    Ken Cox [Microsoft MVP], Dec 9, 2003
    #2
    1. Advertising

  3. Allan M.

    Allan M. Guest

    Yea, I've thought of that. That will work to some degree,
    but it's still just a little bit less cludgy than what
    I've already got working.

    I wish there was a way for the codebehind to pick up what
    values are populated in various dropdowns via client-side
    javascript, without having to write all of these custom
    code hacks.

    The other option I looked at was moving all of our
    existing server side control validation routines to client-
    side javascript. Then the page could only be submitted
    when it was actually DONE. This would prevent the need
    for separate state management mechanisms for javascript
    populated select boxes, because there would be no need to
    redisplay the form the user fills out. Either the form is
    posted processed or a client side validation script would
    halt the form post.

    Once again more javascript. Yuck! There's got to be a
    better way to marry the robust responsiveness of client-
    side scripting and server-side ASP.Net functionality.
    This all-or-nothing (client-side vs. server-side) coding
    methodology really bugs me!



    >-----Original Message-----
    >Hi Allan,
    >
    >Although I haven't tried it, I'm wondering whether you

    could use a hidden
    >server-side input box as a storage area for the populated

    data. Unlike the
    >dropdownlist boxes, input boxes are meant to collect user

    data.
    >
    >Maybe you could store the values in some type of

    delimited string
    >"blue|red|black" that you could parse on the postback and

    add to the
    >listbox?
    >
    >I could be way off the mark here, but thought I would

    raise the possibility
    >in case in sparks something else that suits.
    >
    >"Allan M." <> wrote in

    message
    >news:05c401c3bde4$12e66cb0$...
    >> I have a series of select boxes that must be populated
    >> client side, because they interact with each other. The
    >> design specification calls for these boxes to be updated
    >> without having to make a roundtrip to the server.
    >>
    >> The codebehind seems to be unaware of select box members
    >> populated via javascript. So, I'm having to create my

    own
    >> state management solution, (i.e. rewriting the VIEWSTATE
    >> mechanism) to persist the state of these select boxes
    >> after a postback occurs.
    >>
    >> Is there an easier or better way to do this client-side?
    >> Note: Postback is not an option. That is the way the
    >> code was originally written, but end users were very
    >> unhappy with round trips to server.
    >>
    >> I need a way to be able to update controls using
    >> javascript and include the information in the viewstate
    >> whenever a postback occurs. Is this possible, or is
    >> mixing client-side and server-side form manipulation

    code
    >> just not done in ASP.NET?
    >>
    >> Thanks...

    >
    >
    >.
    >
    Allan M., Dec 9, 2003
    #3
  4. hi
    I m not sure to which answer you are looking for. But easy
    and simples way to connect a server side control to the
    client side control is
    <controlname>.attributes.add("<event name>","<javascript
    function name>");

    Hope this answer might gives you some solution.

    thanks
    srinivas moorthy


    >-----Original Message-----
    >Yea, I've thought of that. That will work to some

    degree,
    >but it's still just a little bit less cludgy than what
    >I've already got working.
    >
    >I wish there was a way for the codebehind to pick up what
    >values are populated in various dropdowns via client-side
    >javascript, without having to write all of these custom
    >code hacks.
    >
    >The other option I looked at was moving all of our
    >existing server side control validation routines to

    client-
    >side javascript. Then the page could only be submitted
    >when it was actually DONE. This would prevent the need
    >for separate state management mechanisms for javascript
    >populated select boxes, because there would be no need to
    >redisplay the form the user fills out. Either the form

    is
    >posted processed or a client side validation script would
    >halt the form post.
    >
    >Once again more javascript. Yuck! There's got to be a
    >better way to marry the robust responsiveness of client-
    >side scripting and server-side ASP.Net functionality.
    >This all-or-nothing (client-side vs. server-side) coding
    >methodology really bugs me!
    >
    >
    >
    >>-----Original Message-----
    >>Hi Allan,
    >>
    >>Although I haven't tried it, I'm wondering whether you

    >could use a hidden
    >>server-side input box as a storage area for the

    populated
    >data. Unlike the
    >>dropdownlist boxes, input boxes are meant to collect

    user
    >data.
    >>
    >>Maybe you could store the values in some type of

    >delimited string
    >>"blue|red|black" that you could parse on the postback

    and
    >add to the
    >>listbox?
    >>
    >>I could be way off the mark here, but thought I would

    >raise the possibility
    >>in case in sparks something else that suits.
    >>
    >>"Allan M." <> wrote

    in
    >message
    >>news:05c401c3bde4$12e66cb0$...
    >>> I have a series of select boxes that must be populated
    >>> client side, because they interact with each other.

    The
    >>> design specification calls for these boxes to be

    updated
    >>> without having to make a roundtrip to the server.
    >>>
    >>> The codebehind seems to be unaware of select box

    members
    >>> populated via javascript. So, I'm having to create my

    >own
    >>> state management solution, (i.e. rewriting the

    VIEWSTATE
    >>> mechanism) to persist the state of these select boxes
    >>> after a postback occurs.
    >>>
    >>> Is there an easier or better way to do this client-

    side?
    >>> Note: Postback is not an option. That is the way the
    >>> code was originally written, but end users were very
    >>> unhappy with round trips to server.
    >>>
    >>> I need a way to be able to update controls using
    >>> javascript and include the information in the viewstate
    >>> whenever a postback occurs. Is this possible, or is
    >>> mixing client-side and server-side form manipulation

    >code
    >>> just not done in ASP.NET?
    >>>
    >>> Thanks...

    >>
    >>
    >>.
    >>

    >.
    >
    srinvas moorthy, Dec 9, 2003
    #4
  5. Allan M.

    Hai Guest

    Hi Allan,

    Regarding avoiding round trips to server I had in my application to use
    Javascript to generate shopping basket.
    My entire section (div) basket is generated via Javascript.
    Part of the code I wrote was:
    parent.frames["basket'].orderdiv.innerHTML = sOrderString;

    WHenever possible I write Javascript to eliminate round trip to server.

    HTH

    Hai

    "Allan M." <> wrote in message
    news:05c401c3bde4$12e66cb0$...
    > I have a series of select boxes that must be populated
    > client side, because they interact with each other. The
    > design specification calls for these boxes to be updated
    > without having to make a roundtrip to the server.
    >
    > The codebehind seems to be unaware of select box members
    > populated via javascript. So, I'm having to create my own
    > state management solution, (i.e. rewriting the VIEWSTATE
    > mechanism) to persist the state of these select boxes
    > after a postback occurs.
    >
    > Is there an easier or better way to do this client-side?
    > Note: Postback is not an option. That is the way the
    > code was originally written, but end users were very
    > unhappy with round trips to server.
    >
    > I need a way to be able to update controls using
    > javascript and include the information in the viewstate
    > whenever a postback occurs. Is this possible, or is
    > mixing client-side and server-side form manipulation code
    > just not done in ASP.NET?
    >
    > Thanks...
    Hai, Dec 9, 2003
    #5
  6. Allan M.

    Peter Blum Guest

    The browser technology (http, etc) is designed to post to the server a very
    limited set of information. The "value" attributes of data entry fields
    (<input> <textarea> <select>) and cookies. The list of text in a droplist is
    simply formatting, not data. So it cannot be transferred.
    The suggestion was made to transfer the value using a hidden input field.
    This is a very popular way of transferring data that doesn't directly appear
    on the page. Microsoft uses this to post back a button's command name via
    the "__doPostBack" function you see on some of your webforms.

    If you are thinking of getting validation on the client side to help,
    remember that many browsers do not support client-side validation. (I sell a
    product called "Professional Validation And More" that supports many more
    browsers than Microsoft's validators.
    http://www.peterblum.com/vam/home.aspx.)

    --- Peter Blum
    www.PeterBlum.com
    Email:

    "Allan M." <> wrote in message
    news:057801c3bdf5$d0d17150$...
    > Yea, I've thought of that. That will work to some degree,
    > but it's still just a little bit less cludgy than what
    > I've already got working.
    >
    > I wish there was a way for the codebehind to pick up what
    > values are populated in various dropdowns via client-side
    > javascript, without having to write all of these custom
    > code hacks.
    >
    > The other option I looked at was moving all of our
    > existing server side control validation routines to client-
    > side javascript. Then the page could only be submitted
    > when it was actually DONE. This would prevent the need
    > for separate state management mechanisms for javascript
    > populated select boxes, because there would be no need to
    > redisplay the form the user fills out. Either the form is
    > posted processed or a client side validation script would
    > halt the form post.
    >
    > Once again more javascript. Yuck! There's got to be a
    > better way to marry the robust responsiveness of client-
    > side scripting and server-side ASP.Net functionality.
    > This all-or-nothing (client-side vs. server-side) coding
    > methodology really bugs me!
    >
    >
    >
    > >-----Original Message-----
    > >Hi Allan,
    > >
    > >Although I haven't tried it, I'm wondering whether you

    > could use a hidden
    > >server-side input box as a storage area for the populated

    > data. Unlike the
    > >dropdownlist boxes, input boxes are meant to collect user

    > data.
    > >
    > >Maybe you could store the values in some type of

    > delimited string
    > >"blue|red|black" that you could parse on the postback and

    > add to the
    > >listbox?
    > >
    > >I could be way off the mark here, but thought I would

    > raise the possibility
    > >in case in sparks something else that suits.
    > >
    > >"Allan M." <> wrote in

    > message
    > >news:05c401c3bde4$12e66cb0$...
    > >> I have a series of select boxes that must be populated
    > >> client side, because they interact with each other. The
    > >> design specification calls for these boxes to be updated
    > >> without having to make a roundtrip to the server.
    > >>
    > >> The codebehind seems to be unaware of select box members
    > >> populated via javascript. So, I'm having to create my

    > own
    > >> state management solution, (i.e. rewriting the VIEWSTATE
    > >> mechanism) to persist the state of these select boxes
    > >> after a postback occurs.
    > >>
    > >> Is there an easier or better way to do this client-side?
    > >> Note: Postback is not an option. That is the way the
    > >> code was originally written, but end users were very
    > >> unhappy with round trips to server.
    > >>
    > >> I need a way to be able to update controls using
    > >> javascript and include the information in the viewstate
    > >> whenever a postback occurs. Is this possible, or is
    > >> mixing client-side and server-side form manipulation

    > code
    > >> just not done in ASP.NET?
    > >>
    > >> Thanks...

    > >
    > >
    > >.
    > >
    Peter Blum, Dec 11, 2003
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    4
    Views:
    506
    Praveen
    Dec 27, 2005
  2. John Kotuby
    Replies:
    1
    Views:
    621
    bruce barker
    Mar 12, 2008
  3. Guest
    Replies:
    2
    Views:
    162
    Guest
    Aug 20, 2004
  4. reneeccwest
    Replies:
    2
    Views:
    124
    reneeccwest
    Jul 12, 2003
  5. palmiere
    Replies:
    1
    Views:
    399
    Erwin Moller
    Feb 9, 2004
Loading...

Share This Page