Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > Codebehind unaware of select box members populated via javascript

Reply
Thread Tools

Codebehind unaware of select box members populated via javascript

 
 
Allan M.
Guest
Posts: n/a
 
      12-08-2003
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...
 
Reply With Quote
 
 
 
 
Ken Cox [Microsoft MVP]
Guest
Posts: n/a
 
      12-09-2003
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." <(E-Mail Removed)> wrote in message
news:05c401c3bde4$12e66cb0$(E-Mail Removed)...
> 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...



 
Reply With Quote
 
 
 
 
Allan M.
Guest
Posts: n/a
 
      12-09-2003
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." <(E-Mail Removed)> wrote in

message
>news:05c401c3bde4$12e66cb0$(E-Mail Removed)...
>> 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...

>
>
>.
>

 
Reply With Quote
 
srinvas moorthy
Guest
Posts: n/a
 
      12-09-2003
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." <(E-Mail Removed)> wrote

in
>message
>>news:05c401c3bde4$12e66cb0$(E-Mail Removed)...
>>> 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...

>>
>>
>>.
>>

>.
>

 
Reply With Quote
 
Hai
Guest
Posts: n/a
 
      12-09-2003
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." <(E-Mail Removed)> wrote in message
news:05c401c3bde4$12e66cb0$(E-Mail Removed)...
> 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...



 
Reply With Quote
 
Peter Blum
Guest
Posts: n/a
 
      12-11-2003
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: http://www.velocityreviews.com/forums/(E-Mail Removed)

"Allan M." <(E-Mail Removed)> wrote in message
news:057801c3bdf5$d0d17150$(E-Mail Removed)...
> 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." <(E-Mail Removed)> wrote in

> message
> >news:05c401c3bde4$12e66cb0$(E-Mail Removed)...
> >> 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...

> >
> >
> >.
> >



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Can *common* struct-members of 2 different struct-types, that are thesame for the first common members, be accessed via pointer cast to either struct-type? John Reye C Programming 28 05-08-2012 12:24 AM
ListBox populated with Javascript shows no members upon Callback John Kotuby ASP .Net 1 03-12-2008 03:33 PM
SELECT dynamically populated probem AC ASP .Net 2 07-20-2005 08:21 AM
Image selector via List Box populated from Database? ASP General 2 08-19-2004 11:56 PM
select of select box will select multiple in another box palmiere Javascript 1 02-09-2004 01:11 PM



Advertisments