Lynx Posted January 17, 2008 Report Share Posted January 17, 2008 Šoreiz gan otrādāk izveidojusies situācija, varbūt tomēr tieši nav ar lielgabalu? :) Stāsts: Man nekādīgi nesanāca uzrakstīt Regexpu, kas starp <script> </script> tagiem javascript stringam izvilktu saturu. Tapēc uzrakstīju šādu variantu: kā redzat izskatās, ka varētu būt overkills salīdzinot ar Regexp - 4 lietojam indexOf(ajax responseText varētu būt ļoti garš, tad to varētu sākt stipri just), 2 temp mainīgie etc. if(request.responseText.indexOf('<script>') != -1 && request.responseText.indexOf('</script>') != -1) { var js_start = request.responseText.indexOf('<script>'); var js_end = request.responseText.indexOf('</script>'); eval(request.responseText.substring(js_start+8,js_end)); } Tapēc neliek mieru jautājums, vai ar Regexp būtu ātrāk, effektīvāk(mazāk koda) un pats galvenais kāds tad varētu izskatīties pats regexps? vienkārši ir padomā pāris testi.. Link to comment Share on other sites More sharing options...
bubu Posted January 17, 2008 Report Share Posted January 17, 2008 Kāpēc tu domā, ka ja indexOf būs lēns, jo garš teksts - tad kāpēc regexpam būtu jābūt ātrākam? Tam tāpat nāktos visus simbolus pēc kārtas pārbaudīt. Regexpus parasti implementē kā galīgus automātus. Un automāti darbojās lasot un apstrādājot pa vienam simbolam no imputa. Tu to otro indexOf vari sākt meklēt tikai no js_start beigām. (beigas nevar būt pirms sākuma :) var js_end = request.responseText.indexOf('</script>', js_start + "<script>".length); Četras reizes gan nevajag izsaukt to indexOf. Pilnībā pietiek ar divām. Pirmo reizi atrodi <script>. Ja tas != -1, tad atrodi </script>. Ja tas nav -1, tad taisi to eval. Un par tavu jautajumu, kas būs efektīvāk - izmēri laiku un salīdzini. Neviens cits tev to nemācēs pateikt :) Ak jā un reku tavs regexps: var tmp = request.responseText.match(/<script>(.*?)<\/script>/); if (tmp) { eval(tmp[1]); } Link to comment Share on other sites More sharing options...
marrtins Posted January 18, 2008 Report Share Posted January 18, 2008 (edited) var tmp = request.responseText.match(/<script>(.*)?<\/script>/); Nebūs tik vienkārši. JavaScripts negribīgi apstrādā newlines (jā, arī ar .*), kā arī, ja starp script tagiem tiks definēts kas tamlīdzīgs: var someString = "<script>Happy!</script>" arī nekas prātīgs nesanāks. Un ja vēl tekstā būs vairāki script tagu bloki... Prasās pēc kādas rekursīvas apstrādes, plus čekot javascript kodu, vai tas nesatur augstāk minētās izvirtības. Edited January 18, 2008 by marrtins Link to comment Share on other sites More sharing options...
bubu Posted January 18, 2008 Report Share Posted January 18, 2008 Nebūs tik vienkārši. JavaScripts negribīgi apstrādā newlines (jā, arī ar .*), Jā tev taisnība. Man piemirsās par newlainiem, ka . nematčo \n. Taču to atrisināt ir ļoti vienākrši - nav problēmu: ...match(/<script>([^]*?)<\/script>/); kā arī, ja starp script tagiem tiks definēts kas tamlīdzīgs: var someString = "<script>Happy!</script>" arī nekas prātīgs nesanāks. Nezinu kas tev tur liekās tik neprātīgs, bet mans uzrakstītais regexps ļoti vienkārši atrod to tavu Happy! Un ja vēl tekstā būs vairāki script tagu bloki...Esmu diezgan pārliecināts, ka autoram ir tikai viens <script> bloks, citādi jau ar indexOf nemeklētu to. Prasās pēc kādas rekursīvas apstrādes, plus čekot javascript kodu, vai tas nesatur augstāk minētās izvirtības. Rekursiju tur toč nevajadzētu. Diez vai kāds taisās <script> iekš <script> likt. Ja būtu tikai vairāki bloki, tad vajadzētu tikai ciklu, kurš meklē un apstrādā vienu pēc otra. Vai arī izmantot global flagu patternam: ...match(/<script>([^]*?)<\/script>/g); Tad tik atgriezts masīvs ar visiem <script>....</script> blokiem Link to comment Share on other sites More sharing options...
Delfins Posted January 18, 2008 Report Share Posted January 18, 2008 un kas notiks, ja būs document.write("</script>"); ;) Link to comment Share on other sites More sharing options...
bubu Posted January 18, 2008 Report Share Posted January 18, 2008 Tādā gadījumā es teiktu, ka tur ir pamatīgi tizla sistēma veidota, ja jau ar javascriptu jādrukā script tagi. Link to comment Share on other sites More sharing options...
marrtins Posted January 18, 2008 Report Share Posted January 18, 2008 (edited) Tas Happy! ir tieši tas, ko Delfins pieminēja. Kāpēc tizla sistēma? Piemēram, arī Extjs to izmanto, lai varētu dinamiski iekļaut cita domēna skriptus un/vai xml. Jā, /g atgriezīs visus blokus, taču ne iekļautu script tagu, piemēram: asdsa <script> alert('<script> tags not allowed!>'); alert('test2'); </script> bb <script> alert('test3'); alert('However, </script> tags IS allowed!>'); </script> cc Edited January 18, 2008 by marrtins Link to comment Share on other sites More sharing options...
bubu Posted January 18, 2008 Report Share Posted January 18, 2008 Lynx: pasaki šiem, ka tev nebūs nekādi iekļautie <script> tagi :) Link to comment Share on other sites More sharing options...
Lynx Posted January 18, 2008 Author Report Share Posted January 18, 2008 (edited) Hahā :) Nebūs man nekādi iekļautie tagi un liels paldies, bubu, par parādīto risinājumu, ļoti noderēja. Reāli šīs regexps ir nepieciešams tikai, lai apstrādātu ajax atgriezto atbildi un izsauktu noteiktas funkcijas, vai izpildītu darības. Un ja pagadās starp <script> tagiem neizpildāms vai gļukojoš kods, tā jau ir server side problēma un to atrisinās pēc pamanīšanas. Tur jau varēja pat script tagus neizmantot, man tas vienkārši šķita visloģiskākais apzīmējums, ko izmantot php izvadītiem datiem, kurus tālāk ir jaevaluē ar javascript. Edited January 18, 2008 by Lynx Link to comment Share on other sites More sharing options...
Delfins Posted January 18, 2008 Report Share Posted January 18, 2008 tad kāda jēga php ģenerēt lapu, ja var atgriezt gatavu kontentu, ko iespraust iekšā, vai gatavu JS kodu, ko tikai jāevaluē, bez jebkādiem tagiem un t.t. Vot tas ir īsts AJAX (sūtam request, lai atpakaļ izpildītos JS kods, neiejaucoties pa vidu) Link to comment Share on other sites More sharing options...
Lynx Posted January 18, 2008 Author Report Share Posted January 18, 2008 (edited) Nu galvenā problēma ir tā, ka 90% gadījumos tiek atgriezts uzģenerēts tīrs html, kas ārī bez problēmām tiek attēlots. Un šeit lietot tīru js, lai uzģenerētu šo te pašu html contentu DOM kokam jau būtu overkills. Šoreiz, tapēc, ka ļoti js intensīvs projekts un svarīgāks ir js izpildes ātrums nevis aizsistais bandwidth. Un dažreiz ir arī nepieciešams izpildīt kopā ar atgriezto html arī kādu js kodu un šis šķiet daudz effektīvāks variants nekā taisīt ntās funkcijas iekš headeros inkludotā js faila. Edited January 18, 2008 by Lynx Link to comment Share on other sites More sharing options...
bubu Posted January 18, 2008 Report Share Posted January 18, 2008 Nez vai eval būs tas efektīvākais varients, nekā jau ielādētas js funkcijas. Tās pēdējās jau ir noparsētas un nokompilētas baitkodā pie lapas ielādes - atliek tikai izpildīt tās. Taču tas, kas jāizpilda ar evalu ir jāparsē un jākompilē uz baitkodu no jauna, un tikai pēc tam to kodu var izpildīt. Link to comment Share on other sites More sharing options...
Recommended Posts