Andra P žurnāls

Ja aktīvi strādājat ar jQuery, noteikti būsiet pamanījuši, ka parasti dokumentācija ir ļoooti lēna. Tik lēna, ka pat reizēm neveras vaļā. Kamēr paši džīkveristi nav atrisinājuši šo problēmu, ir jāmeklē cits risinājums alternatīvu dokumentāciju veidolā. Par laimi tādas ir vairākas:

• jQuery API - Vienkāršs interfeiss, kur navigācija notiek pēc alfabēta. Ir iespējams meklēt. Rakstīšanas brīdī jQuery API versija 1.2.6.
• jQuery API Browser - Ļoti ērta dokumentācija, kur var navigēt gan pēc kategorijām, gan pēc alfabēta. Ir arī meklēšanas iespēja. Plus, ka šo dokumentāciju var lejupielādēt un lietot lokāli bez interneta pieslēguma. Rakstīšanas brīdī jQuery API versija ir 1.1.2.
• Visual jQuery - Interesanti norealizēta navigēšana. Tāpat kā jQuery API Browser, arī šo ir iespējams lejupielādēt un izmantot bez interneta pieslēguma. Rakstīšanas brīdī jQuery API versija ir 1.1.2.

Ceru, ka arī jums noderēs. ;)

Google Chrome ir iznācis un visi priecājas cik ātrs un vienkāršs tas ir, bet man kā web izstrādātajm interesē, vai tam ir, nu jau varētu teikt par standartu kļuvušie, web developer rīki. Un izrādās, ka ir. :)

Atrast tos gan nemaz nebija tik viegli. Latviešu valodā tie slēpjas zem:

Kontrolēt esošo lapu poga (tā, kas uzreiz pa labi no address bar) > Izstrādātājs > JavaScript pults.

Angliskajā interfeisā attiecīgi:

Control current page poga > Developer > JavaScript console.

Atverot šo dialoglogu, biju pārsteigts, ka Google’s ļaudis jau laikus visu centušies izdarīt kā vajag. Ir smuks HTML DOM koks, pa kuru varam staigāt. Ir JS console. Katram elementam varam apskatīt CSS:

Varam arī apskatīt arī elementa izmērus lapā:

Un, protams, arī elementa DOM objekta īpašības:

Braukājot ar peli pa DOM koku, elements lapā tiek izgaismots, bet tiesa gan – tikai tā izmērs bez margin (malām). Nav iespēju kā Firebug ar peli braukāt pa pašu lapu un uzreiz izgaismot elementu (kā arī DOM kokā redzēt, kurš elements iekrāsojas), bet var ar labo peles pogu nospiest uz elementa un izvēlēties Pārbaudīt elementu.

DOM kokā ir iespējams arī meklēt:

Žēl gan, ka nav iespējams labot vai atslēgt CSS, tāpat arī, kad mēģināju ar dubultklikšķi atvērt kādu DOM HTML, lai palabotu, man atvērās vienkārši tukšs ekrāns bez iespējas tikt atpakaļ uz DOM koku.

Ejam tālāk. Ir iespējams arī apskatīt HTTP pieprasījumus. Varam apskatīt gan cik katrs objekts procentuāli aizņem no kopējiem KB, gan cik daudz laika procentuāli no kopējā laika pavadīts, lai ielādētu elementu.

Tiesa gan – es tā arī īsti nesapratu pēc kāda principa tie tiek kārtoti.

Patīkami, ka var nospiest uz objekta uz ērti apskatīt, kas tas ir. Ja tas ir CSS, HTML vai JS, tad tā tekstuālo saturu. Ja attēls, tad attiecīgi pašu bildīti:

Nedaudz padarbojoties ar Javascript konsoli, novēroju, ka objektiem ir pat autocomplete iespēja. Tiesa gan – es tik reti izmantoju JS konsoli, ka īsti labums man personīgi no tā nav.

Neizmēģināju gan vai ar šo rīku ir iespējams debugot XmlHttpRequest (Ajax) pieprasījumus, bet no pirmā acu uzmetiena nekas neliecina, ka tur kaut kas tāds ir paredzēts.

Katrā ziņā pārlūks izskatās ļoti cerīgi. Ja jau pirmajā relīzē ir pieejami izstrādātāju rīki, tad cepuri nost Gūglei. :)

Starp citu, W3C jau kādu brīdi piedāvā validēšanas rīku arī priekš HTML 5. Tiesa gan - eksperimentālā statusā. Bet, protams, kā tad savādāk, jo pats HTML 5 standarts arī vēl ir tikai izstrādes procesā.

Internet Explorer 8 atbalstīšot tā saukto “porn režīmu”. Protams, oficiāli tas tā netiek saukts, bet nu visiem jau ir skaidrs kā tas 99% gadījumu tiks izmantots.

Tie kas nezin - tas ir tāds režīms, kad pārlūks “neatceras” pilnīgi neko, kas ar to ir darīts šī režīma darbības laikā. Nekas nepieglabājas ne iekš history, ne cache. Domāju, ka kukiji, kas izveidoti šī režīma laikā, arī tiek izdzēsti, kad sesija tiek pārtraukta.

Bez tā ir vēl dažādas privātuma papildiespējas, bet par tām palasiet paši, ja ir interese.

Šodien braucot uz darbu ar velo, nācās gabaliņu pabraukt pa ceļa braucamo daļu, nevis kā ierasts, pa trotuāru. Līdz šim to tā pārāk nebiju pamanījis, bet bez tā jau mazās josliņas pa kuru riteņbraucējam jāizmanierē, lai garāmbraucošās mašīnas to neaizķertu, vēl papildus šķērsli tiek likti notekūdeņu šahtu (tā nosaukt tos kvadrātveida restainos caurumus asfaltā?) veidā. Vienmēr tās ir realizētas kā padziļinātas bedres, un pie pašas apmales. Tieši tur, kur jābrauc riteņbraucējiem. Protams, tās var apbraukt, bet tā vēl vairāk riskējot tiktam aizķertam. Var jau arī mēģināt braukt pāri (un tā arī pāris reizes man ir nācies), bet nu ja bedre dziļāka, tad var gadīties arī pazaudēt līdzsvaru vispār.

Jā, tajās reizēs, kad ceļa malā ir atļauts stāvēt automašīnām, un tās to parasti arī dara, tad it kā velobraucējam vajadzētu varētu atviegloti uzelpot. Bet nē - tad ir cits šķērslis - autovadītāji, kas laikam vadās pēc dzirdes nevis pēc redzes, un durvis ver uz ielas pusi nepaskatoties vai kāds tuvojas vai nē. Un tas ir vēl trakāk par bedrēm.

Es negribu pārmest neko autovadītājiem, jo zinu, ka velobraucēji vēl vairāk neievēro satiksmes noteikumus. Bet nu tiem dažiem indivīdiem, kas man personīgi ir pašā priekšā atvēruši durvis braucamās daļas pusē, ka knapi paspēju apbraukt, tiešām gribu novēlēt pašiem ietriekties tajās durvīs.

Tie, kas seko līdzi Photoshop Disasters (PD) blogam, droši vien jau būs redzējuši šo (Attēls sperts no PD). :)

Pati universitātes lapa, kur to var redzēt dabā.

Kādu mazu brītiņu jau ir pieejama jaunāka NetBeans, oriģināli paredzēta priekš Java valodas, IDE versija 6.5 beta (tātad versija ir izkāpusi no early preview statusa), kas mums, PHP programmētājiem, var likties interesanta, jo tajā ir vairāki speciāli PHP (un arī HTML/JS/CSS) paredzēti jaunumi.

Bez jau standartā pieejamām iespējām, NetBeans tagad piedāvā arī PHP koda auto-pabeigšanu (code complete), sintakses izgaismošanu, kā arī ir XDebug atbalsts. Cik papētīju dažādus skrīnšotus , ir arī vēl dažādu citu sīkumu, bet tos atrodiet un apskatiet paši. ;)

Bez tam ir arī iebūvēts Javascript redaktors un debugeris, kā arī dažādu populāru Javascript framework atbalsts (piemēram, tas pats JQuery).

Kādu laiku atpakaļ jau izmēģināju early preview versiju, bet tā diemžēl bija pārāk nestabila (ļoti bieži vienkārši sasala), tāpēc ātri vien tiku no tās vaļā un neizmēģināju visus (ar PHP saistītos) labumus. Bet tagad būs jādod vēl viena iespēja. :)

Lejupielādēt var šeit.

John Resig (JQuery izstrādātājs) turpmāk pusi no sava darba laika Mozilla paspārnē pavadīšot pie Firebug izstrādes. Ir izveidota speciāla Firebug komanda, kur bez John Resig strādās vēl arī Jan Odvarko un Rob Campbell. Šie vārdi gan varbūt nav tik pazīstami. :)

Pagaidām gan man neizdevās atrast neko par nākotnes plāniem (plānotām jaunām Firebug iespējam u.t.t.), bet domāju, ka speciālas izstrādes grupas izveide (un John Resig pievienošanās tai) noteikti nozīmē, ka gan jau drīzumā varēsim sagaidīt jaunas un noderīgas lietas.

Varbūt nepamanījāt, bet vakar bija tas datums (08.08.08), kad oficiāli vairs netiks atbalstīts PHP 4. Tas nozīmē, ka vairs nebūs jaunu versiju un netiks laboti caurumi. Vēl aizvakar paguva izlaist pēdējo bug fix relīzi 4.4.9, bet tad tas arī būs viss.

Nu tad - lai dzīvo PHP5! :)

Ja jums ir gadījies saskarties ar virsrakstā pieminēto kļūdu, bet tā arī neizdevās to atrisināt (vai arī izdevās, bet tā arī nesapratāt, kas bija par vainu), tad varu pastāstīt, ka tam iemesli var būt divi. Vismaz divi populārākie. Par citiem nezinu.

Pirmais un vienkāršākais

Kādas klases destruktors (__destruct() metode) mēģina mest Exception’u.

Otrais, nedaudz nedaudz sarežģītāks.

Ja ir definēts savs speciālais Exception’u handleris, bet kā gadījies kā nē, bet šis handleris pats arī nestrādā kā nākas un met Exception’u.

Piemēram:

<?php

    function my_exception_handler($exception) {

        // Exception's iekš Exception'a ? Nē, tā nu nevarēs...
        throw new Exception('Kaut kas notika kļūdas apstrādes procesā!'); 

    }

    // uzstādām, lai my_exception_handler() apstrādā mūsu Exception'us
    set_exception_handler('my_exception_handler'); 

    // Šis attiecīgi liks izpildīties my_exception_handler() funkcijai
    throw new Exception('Kļūda!');

?>

Tas pats notiks arī, ja Exception’u metīs kāda cita funkcija vai klases metode, kas izsaukta no my_exception_handler().

Es īsti nemācēšu pastāstīt, kas notiek apakšā, kādēļ šī kļūda notiek, bet domāju, ka pietiks ar šādu pragmatisku “atrisinājumu”. :)

Aizmirsu svarīgāko - pašu atrisinājumu otrajam variantam :)

Kodu, kas met Exception’u, vajag ielikt try {} catch () {} struktūrā. Ar to arī pietiks.

Vairāk gūglē.