Prev: how to retrieve a dom from innerHTML......
Next: could use some suggestions to speed this short piece ofcode up
From: "Daevid Vincent" on 19 Jan 2010 23:55 I have an HTML form with a hundred or so elements on it, used for searching a database. When the user submits the form (via GET) the URL is loaded with ALL of these fields, and many of them are not even actually used in the search criteria. https://mypse/dart2/ps_search.php?enter_date=2009-11-30&id_incident=&incide nt_date=&incident_hh=0&incident_mm=0&id_urgency_level=0&problem_description =&immediate_action=&unit_opened=&unit_authorized=&customer=&customer_contac t=&customer_address=&customer_country=&id_location=0&passengers_onboard=&su bmit=Search&part_number=&serial_number=&nomenclature=&manufacture_date=&mod _level=&id_lru_condition=&repair_history=&ac_type=&tail_number=&id_system_t ype=&id_lru_location=0&circuit_breaker=&circuit_breaker_amps=&seat_number=& seat_vendor=&seat_column_zone=&seat_zone=&tc_holder=&stc_holder=&asr_mor=&i mpounded=&id_authority=&id_region=&reported_by=&prepared_by=&preparer_locat ion=&field_engineer=&id_attach_pictures=&id_attach_mlr=&id_attach_lopa=&cab in_log=&parts_inspect=&id_organization=0&id_quality_engineer=0&car_number=& close_date=&closed_by=&qa_comment=&id_priority=&id_action=0&id_incident_sta tus=3&id_failure_type=&detail_status=&investigation_result=&osaka_action=&o saka_request=&newvsrepeat=&related_incident=&unit_received_date=&unit_retur ned_date=&tdr_to_pso_date=&tdr_date=&dcr_date=&dcr_reference_number=&ecr_da te=&ecr_reference_number=&eco_date=&eco_reference_number=&service_bulletin_ date=&sb_reference_number=&sil_issue_date=&sil_reference_number=&til_issue_ date=&til_reference_number=&customer_letter_issue_date=&subassembly=&rdm=&p svector=&oemmanuf=&defective_part_1=&defective_part_2=&defective_part_3=&de fective_part_4= Is there some way via PHP/Apache Mod/Javascript to remove all the keys that don't have any value in them and just distill this down to the elements/keys that the user actually entered some input for? ie. defaulting all the rest to 'blank'. In PHP, this would look something like this: foreach ($_GET as $k => $v) if ($v == '') unset($_GET[$k]); The problem as I see it, is that this "magic" happens when the user hits "Submit", so not sure PHP has any way to intercept at that point. Javascript might be able to do something on the "onClick" event or "onSubmit" I suspect. But this seems like something that someone should have solved before and common enough that I would think Apache could handle it transparently with a directive or module enabled so I don't have to code some hack on every page. I guess I could always redirect to some 'scrubber' page that strips them out and redirects on to the refering page again, but that seems klunky. BTW, I want to use GET so that the page can be bookmarked for future searches of the same data (or modified easily with different dates, etc.), so that's why I don't use POST.
From: "Michael A. Peters" on 20 Jan 2010 00:39 Daevid Vincent wrote: *snip* > > The problem as I see it, is that this "magic" happens when the user hits > "Submit", so not sure PHP has any way to intercept at that point. > Javascript might be able to do something on the "onClick" event or > "onSubmit" I suspect. But this seems like something that someone should > have solved before and common enough that I would think Apache could handle > it transparently with a directive or module enabled so I don't have to code > some hack on every page. > > I guess I could always redirect to some 'scrubber' page that strips them > out and redirects on to the refering page again, but that seems klunky. > > BTW, I want to use GET so that the page can be bookmarked for future > searches of the same data (or modified easily with different dates, etc.), > so that's why I don't use POST. > JavaScript is the only client side way I know of. Use document.getelementbyid() and yank the unused nodes before submit. server side, redirect - it shouldn't be that clunky. Put in a hidden input that tells your action script to redirect to itself without the unused get variables (and w/o the hidden input). That's how I would do it personally (opposed to js).
From: "Michael A. Peters" on 20 Jan 2010 00:44 Daevid Vincent wrote: > > I guess I could always redirect to some 'scrubber' page that strips them > out and redirects on to the refering page again, but that seems klunky. > > BTW, I want to use GET so that the page can be bookmarked for future > searches of the same data (or modified easily with different dates, etc.), > so that's why I don't use POST. > Another option is to use post in the form, and when your action page receives post, it redirects to itself with the used variables as get.
From: Ashley Sheridan on 20 Jan 2010 08:26 On Tue, 2010-01-19 at 20:55 -0800, Daevid Vincent wrote: > I have an HTML form with a hundred or so elements on it, used for searching > a database. > > When the user submits the form (via GET) the URL is loaded with ALL of > these fields, and many of them are not even actually used in the search > criteria. > > https://mypse/dart2/ps_search.php?enter_date=2009-11-30&id_incident=&incide > nt_date=&incident_hh=0&incident_mm=0&id_urgency_level=0&problem_description > =&immediate_action=&unit_opened=&unit_authorized=&customer=&customer_contac > t=&customer_address=&customer_country=&id_location=0&passengers_onboard=&su > bmit=Search&part_number=&serial_number=&nomenclature=&manufacture_date=&mod > _level=&id_lru_condition=&repair_history=&ac_type=&tail_number=&id_system_t > ype=&id_lru_location=0&circuit_breaker=&circuit_breaker_amps=&seat_number=& > seat_vendor=&seat_column_zone=&seat_zone=&tc_holder=&stc_holder=&asr_mor=&i > mpounded=&id_authority=&id_region=&reported_by=&prepared_by=&preparer_locat > ion=&field_engineer=&id_attach_pictures=&id_attach_mlr=&id_attach_lopa=&cab > in_log=&parts_inspect=&id_organization=0&id_quality_engineer=0&car_number=& > close_date=&closed_by=&qa_comment=&id_priority=&id_action=0&id_incident_sta > tus=3&id_failure_type=&detail_status=&investigation_result=&osaka_action=&o > saka_request=&newvsrepeat=&related_incident=&unit_received_date=&unit_retur > ned_date=&tdr_to_pso_date=&tdr_date=&dcr_date=&dcr_reference_number=&ecr_da > te=&ecr_reference_number=&eco_date=&eco_reference_number=&service_bulletin_ > date=&sb_reference_number=&sil_issue_date=&sil_reference_number=&til_issue_ > date=&til_reference_number=&customer_letter_issue_date=&subassembly=&rdm=&p > svector=&oemmanuf=&defective_part_1=&defective_part_2=&defective_part_3=&de > fective_part_4= > > Is there some way via PHP/Apache Mod/Javascript to remove all the keys that > don't have any value in them and just distill this down to the > elements/keys that the user actually entered some input for? ie. defaulting > all the rest to 'blank'. > > In PHP, this would look something like this: > > foreach ($_GET as $k => $v) if ($v == '') unset($_GET[$k]); > > The problem as I see it, is that this "magic" happens when the user hits > "Submit", so not sure PHP has any way to intercept at that point. > Javascript might be able to do something on the "onClick" event or > "onSubmit" I suspect. But this seems like something that someone should > have solved before and common enough that I would think Apache could handle > it transparently with a directive or module enabled so I don't have to code > some hack on every page. > > I guess I could always redirect to some 'scrubber' page that strips them > out and redirects on to the refering page again, but that seems klunky. > > BTW, I want to use GET so that the page can be bookmarked for future > searches of the same data (or modified easily with different dates, etc.), > so that's why I don't use POST. You can't remove the empty fields server-side, as they never reach the server. GET has a limit on the amount of data it may carry, which is reduced the longer the base URL is. If you need to send large amounts of data like that, you need to send it via POST. You can make minimal changes to your PHP code to allow for this. If you use $_GET in your PHP, swap it for $_REQUEST which contains both GET and POST data. Thanks, Ash http://www.ashleysheridan.co.uk
From: "Michael A. Peters" on 20 Jan 2010 13:30
Rene Veerman wrote: > Michael, while i respect your choices, i think you should know that > jquery.com is pretty good at minimizing browser-incompatibility > headaches (and keeping js apps small), and the quircks that are left > are easy enough to learn about. > > for things whereby > - the server needs to generate tons of HTML for a small(ish) dataset, or > - the client generates data (also to be translated to html) that the > server doesnt really need to know about (yet) > > js can really take some stress off the server. I also like to run any content that has user contributed data through a server side filter that enforces Content Security Policy - http://www.clfsrpm.net/xss/ That filter makes sure the content sent to the browser does not include stuff that violates the defined CSP, and thus greatly reduces the risk of malicious content that input filtering missed from reaching the end user. Furthermore, when it does catch a violation, it reports the violating to a log file notifying me of the problem. The only way that works for content generated client side would be if the user was running a browser that is CSP aware, and right now, they just don't exist. Firefox has an experimental add-on for CSP but virtually no one uses it. Doing dynamic content server side allows me to run that content through the enforcement filter server side thus catching policy violating content before it is ever sent to the user. That itself, btw, is probably the biggest stress on the server. I understand prototype etc. is the "web 2.0" way but I really don't have a high opinion of "Web 2.0". JavaScript, flash, etc. all have been used far too often to do bad things. Right now, if I don't block except for white listed web sites, I end up with advertisements I don't care about expanding and covering the content I do care about. Unfortunately the web is full of jerks who do rude things with scripts, and people who do malicious things with scripts. You wouldn't execute code that someone you don't know sent you an e-mail, would you? I wouldn't, nor do I execute code someone I don't know embeds in a web page. I surf with script blockers (NoScript to be specific) and when I come upon web sites that don't properly function, I'm a lot liklier to head elsewhere than to enable scripting for that site. Since I surf that way, I expect others do as well, doing things server side that can be done server side allows users like me who block scripting to access the content without compromising the security of our systems. |