Jump to content
php.lv forumi

gurkjis

Reģistrētie lietotāji
  • Posts

    252
  • Joined

  • Last visited

Posts posted by gurkjis

  1. atceros šo tēmu.

     

    Jā, var JSON glabāt arī ar UTF-8 simboliem, nevis kā eskeipotus kodus \uNNNN. Pie lieliem JSON gabaliem tas samazina gan izmēru. Uz PHP to var izdarīt ar:

    json_encode($data, JSON_UNESCAPED_UNICODE);

     

    info: http://php.net/manual/en/json.constants.php

    šī fīča pieejama kopš PHP 5.4

     

    Autors gan meklē risinājumu priekš Javascript.... 

    Es Chrome konsolē patestēju:

    JSON.stringify({ a: 'ģļāžšķūņū' })

    - utf-8 simboli paliek kā ir.

     

    Un šeit teikts, ka tas ir no pārlūka atkarīgs, daļa json taisa utf-8 as-is, bet daļa kā eskeipotu:

    http://stackoverflow.com/questions/3862430/differences-in-json-stringify-result-between-browsers:

  2. Ja runājam par servera vidi, tad es ieteiktu lēnām migrēties no Apache uz kaut ko citu, nākamais, viens no populārākajiem variantiem ir nginx, bet ir vēl vairāki citi varianti kā lighttpd, utt.

     

    Jo es neredzu iemeslu, kāpēc lai caring devs varētu gribēt dzīvot uz Apaches, neskaitot vecus ieradumus un ignoranci. 

    Apache ir lēna un bloated. Daudzi to lieto, jo tas ir ieradums, kas izveidojies pirms daudziem gadiem. Pirms 5 gadiem varbūt alternatīvas nebija un informācija par tām bija maz, nebija labi testētas, utt. Bet tagad šādas iespējas ir.

  3. Uz normāla frameworka / CMS arī vajadzētu varēt standarta lietas ātri salipināt, kas neprasa arī baigo iedziļināšanos sistēmas internāļos. Tas patiesībā ir labi. Attiecīgi rodas laiks uz dažādiem sīkumiem un niansēm, lai projektu pieslīpētu individuāli.

     

    Wordpress kaut kādā mērā šo uzdevumu izpilda, bet problēmas sākas,kad no GUI režīma ir jāpāriet uz kodu, jo darbs ar to ir pielīdzināms smagai izvarošanai bomzīgā Ņujorkas šķersielā. Bet nu gaumes jau atšķiras... es domāju,ka daudzi to akceptē, jo neko labāku nespēj iedomāties / nav redzējuši.

     

    Tāpat arī, vienkāršiem kompānijas un projektu vadītājiem parasti neinteresē, kāds tas kods ir, viņi redz tikai GUI un plugins, bet tas arī viss. Ar kodu MAN ir jāsastopas! 

  4. "brīvī tipētās valodas "  patiesībā ir slikta lieta. Labāk būt specifiskiem un sašaurināt problēmu iespējamību, skaidri definējot kas kur paredzēts, mazinot mulsuma momentus.

     

    Kaujā specifisks vs universāls, specifiskums uzvar.

     

    Ir gadījumi, kad dinamiski objekti perfekti iederās problēmas risinājumā, bet tie ir tikai daži gadījumi, bet šī jau atkal ir specifiskuma pieeja, kad mēs izvērtējam, kurā gadījumā lietot pareizos risinājumus, un kuros strikti tipi labāk kalpo.

  5. Pēc id ir labāk, nekā pēc nosaukuma. Tas ir "minimālais apmierinošais risinājums". Tas ir - ja nosaukums tiks pamainīts kategorijai, tad visi vecie URĻi nobruks. 

     

    Viņš ir iesācējs, ja sāks vēl slugs implementēt, tas radīs nevajadzīgu papildus slodzi. 

     

    Lai tiek galā ar obvious lietām un tad var domāt par ekstrām un smukumiem.

  6. Ok ja gribi atlīdzināt, tad ņem vērā un centies realizēt šādas lietas, lai pasauli padarītu labāku:

     

    1. maksimāli, kur notiek kaut kāda datu sagatavošana, vai izvilkšana no db, to liec pirms templeita izvadīšanas

    2. varbūt labāk paņem kādu frameworku, kurā būtu vienkārši lietojams ORM, nevis pliku php aiztiec un raksti primitīvus kverijus ar roku

    3. kāpēc 1. līmeņa un 2. līmeņa kategorijas Tev ir atsevišķās tabulās ? Tām taču ir kopēja nozīme un loģika, var likt vienā tabulā... Tādā gadījumā pietiktu ar 1 kveriju.

  7. Ar to query nedabūsi tādu struktūru.

     

    Es darītu tā, ka uztaisītu 2 atsevišķus kverijus, vienu uz `category` tabulu un otru uz `globcat`, 

    pēc tam ar php foreach ietu cauri pirmajam masīvam, un iekšā uztaisītu otru foreach, kas balstoties uz parent_id, izvelk subitemus.

     

    Apmēram tā:

    <?php
    
    $globcats = array();
    $q = mysql_query("SELECT * FROM `globcat`") or die(mysql_error());
    while ($row = mysql_fetch_assoc($q)) {
      array_push($globcats, $row);
    }
    
    $subcats = array();
    $q = mysql_query("SELECT * FROM `category`") or die(mysql_error());
    while ($row = mysql_fetch_assoc($q)) {
      array_push($subcats, $row);
    }
    
    
    ?><div id='cssmenu'>
    <ul>
    <?php foreach ($globcats as $globcat): ?>
       <li class='has-sub'><a href='#'><span><?php echo $globcat['catname'];?></span></a>
          <ul>
             <?php foreach ($subcats as $subcat): ?>
               <?php if ($subcat['parent_id'] == $globcat['id']): ?>
                 <li><a href='#'><span><?php echo $subcat['name'];?></span></a></li>
               <?php endif; ?>
             <?php endforeach; ?>
          </ul>  
       </li>
    <?php endforeach; ?>
    </ul>
    </div>
    
  8. Lietoju standarta tēmas, ar baltu fonu... mazliet grūti pierast, ja mainu IDE, bet slinkums līst settingos un uzlikt sev ideālās krāsas. Bet nu tā kā esmu ievērojis sakarību, ka pēc laika pierodu, tad tagad jau elastīgāk pārmaiņas uztveru.

     

    Mani tracina, kad IDEi salieku settingus un tad kaut kas jāpārinstalē, un viss nobrūk / pazūd, protams, var atsevišķi vēl ņemties ar Export/Import, bet netīk. Kruti būtu, ja varētu nospiest "Sync to cloud" un miers, bet nu kaut kā neredzu šo fīču sevis lietotajās vidēs (FlashDevelop, PHPStorm un Notepad++).

  9. Mans prāts neko citu nepieņem, objekti vienmēr ir un būs, kuri ir jāapstrādā... 

    Ja Tev ir kompleksa problēma, tad Tu to izdali objektos un darbībās ar tiem.... kā gan savādāk.. nevaru nekādi iedomāties.. 

     

    Esmu dzirdējis, ka eksistē "funkcionālā" programmēšana, kad Tev ir funkcija, kura paņem tiešo input parametrus, un uzreiz izvada output, nekam citam nekur nepieskaroties, bet man tas izklausās pēc šausmīga limitējuma... Piekrītu, ka kaut kādās situācijās (ja nemaldos, multithreading gadījumā), šāda taktika ir ļoti veselīga, bet citādi ikdienā tas izskatās pēc hardcore rāmjiem, kuros būtu sevi jāierobežo.

  10. Domāju, ka kļūda parādīsies neatkarīgi no tā, ko dara Tavs skripts (salīdzina Content-length vai arī nē), jo tas warnings izmetas pirms skripta izpildes (t.i. pie HTTP pieprasījuma parsešanas). Tur nav variantu, kā vien mainīt konfigurāciju.

  11. Nu nevajag jau trakot tāda nieka dēļ.

     

    php vienmēr ir šis te limits, kas ir jānorāda. php.ini failā nomaini post_max_size uz sev vēlamo izmēru. Un arī upload_max_filesize jāliek tāda pati vērtība, tad darbosies.

     

    Bet ja Tev vajag 1 gb uploadus, tad ar php standarta mehānismu diezvai tas izdosies.

    http://stackoverflow.com/questions/3836417/1gb-file-upload-using-php

     

     

     

    Man nevajag lai lielākus failus varētu ielādēt.
    - vienkāršāk ir palielināt upload limitu, nekā ravēt ārā/slēpt konkrēto warningu. Var atslēgt visus warningus, bet tas nav veselīgi, jo savādāk nezināsi, ka sistēmā notiek kas neriktīgs.
×
×
  • Create New...