views:

170

answers:

5

I'm creating a webform that has combos containing 100 values or so. The values are the same.

The form may have several records. So if there are 100 records there are 10,000 lines which seems pretty wrong from a "download" point of view.

The thing is: I want to keep that combo dynamic to keep the id from the database.

So I came up to the following:

  .....
 <script>
      stupidCombo = "<option>a"+
                    "<option>b"+
                    ...
                    "<option>99zzz"+
                    "</select>";
 </script>
 ..... form here
 .... for each item in huge list do paint <table><tr> etc. etc 

 <td>
 <select name="comb-<%=id%>">
      <option selected><%=obj.val%>
      <script>document.write(stupidCombo);</script>
 </td>
... close form, table, html etc.

I have rendered it and "look" fine. The page has decreased from 50k lines to 5k and the select is created by the javascript on the client side.

My question is.....

Is this ok?

Is there any risk involved?

I borrow this Idea after understanding who most of the javascript frameworks work, but most of them work on a <div> element rather that just to the document it self.

I'm targeting IE6 and this is a quick fix that has to be on production tomorrow morning ( so I don't want to spend too much time on this ) but I don't want to have 50,000 lines written for each request if I can help it.

Thanks

+1  A: 

well it obviously won't work if javascript is disabled.

rikh
A: 

Google does it ("document.write") all the time (Analytics/Adsense/...), so I don't see why there would be anything wrong with it.

Your solution does look a bit odd, because the <script> tag is inside a <select> tag, so you better check in several browsers. After all, you never know what IE is going to do :)

Philippe Leybaert
That's exactly my concern :S .. .I just need ie6 by now, since this is an "emergency" fix ( you know is something that only happens were I work and nowhere else in the world right? ) :)
OscarRyz
+1  A: 

HTML produced by document.write works in same way as normal one, so there is no any technical problems with your solution. ( of course, such solution works only if javascript enabled )

By the way, for the lists with big count of options, you can look at "suggest box" component, which can replace native selectbox

Aquatic
Yeap, I didn't feel like adding a framework for I have only a couple of hours to complete this small form and I didn't want to add another thing into the mix.
OscarRyz
+3  A: 

HTTP compression (mod_gzip, etc.) will compress all that nicely.

If you insist on document.write, you will have to use JavaScript to write <select> element as well, because in HTML you're not allowed to put <script> inside <select>.

Another approach is to send one copy of the control to the browser and then duplicate it with help of selectElement.cloneNode(true).

porneL
<-- this, please avoid doc.write
annakata
:-/ ... that's what I'm afraid to.. The thing is, If I include the <select> I miss the change to dinamically set the object.id :'( I guess I'll leave it in plain HTML. I don't want to have a nasty surprise tomorrow morning.
OscarRyz
A: 

Update.

I've done just the way I asked and it worked fine. There were no problems with the js inside ie.

But...

Once the table is rendered, the next thing the user attempt to do ( always the user does something unexpected ) was..

"Ok, the report looks fine. I'm going to copy/paste it into MS-Excel thank you."

Which is something that I don't really care. Is up to the user, but the result was: The excel spreadsheet die ( or froze which is almost the same)!!!! because the javascript engine within the excel is not as good as it is inside IE, the combos took forever to copy and actually it leave excel application unusable.

I didn't knew the copy/paste was so good from IE to Excel that it actually copied all the generated html and Excel tried to run the javascript too with terrible results.

I'll try again by leaving the raw html and see if that works better.

:(

OscarRyz