gurkjis

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:

Patīkams iespaids.

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.

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!

To programmēja deputātu dēli. :>

Ja negribās ar tiem php Java extension ņemties, tad java var izsaukt caur komandrindu, padodot parametrus un nolasīt outputu. Tiesa, tas būs vēl "perversāk", toties var uzkodēt viens divi.

"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.

Wuu, ko škendējies ? Tev nepatīk tieši PHP vai arī pati programmēšana vispār ? Ilgtermiņā darīt to, ko nepatīk darīt, tas nav veselīgi.. Izvēles iespējas vienmēr pastāv.

tātad resolvēšanu veicam tikai līdz id segmentam un pēdējo nosaukuma slug segmentu ignorējam.. tādējādi pie nosaukuma maiņas vienmēr atvērsies korekta lapa - ok, laba ideja.

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.

kategorijas gan urlī, gan kverijā norādi ar id... pēc nosaukuma nevajag identificēt. Katrai precei jābūt category_id, pēc tās arī tad taisi selectu un iegūsi preces,kas ir šajā kategorijā.

āh, ORMam pat nevajag veselu frameworku, man pašam patika lietot http://redbeanphp.com/ - super ērts. Modernos PHP frameworkus neesmu lietojis, bet esmu lasījis, ka labi ir http://laravel.com/ un http://fuelphp.com/ Manā skatījumā, iesācējam labs frameworks ir tāds, kurš ir viegli apgūstams un lietojams. Taču šajā jautājumā varbūt citi foruma biedri varētu ko ieteikt.

Ar individuālām konsultācijām nenodarbojos. Kad saliksi 1. un 2. līmeņa kat. vienā tabulā, tad arī būs 1 selektā, tikai 1. līmenim parent_id būs 0.

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.

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>

mysql str_replace: REPLACE(): http://davidwalsh.name/mysql-replace mysql base_convert: CONV(): http://stackoverflow.com/questions/2267422/mysql-equivalent-of-phps-base-convert

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++).

Prasās plūstošākas animācijas (lielāku update FPS uzlikt).

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.

nez, man 9:00 - 18:00 liekas biedējoši. Nevar strādāt, balstoties uz reāli padarīto ? Beigās taču nozīme ir tam, kas reāli fiziski ir padarīts.

Atkarīgs, kā PHP lieto... iespējamību telpa ir gigantiska... Jaunajās versijās ir sexy OOP features, ja uz vientuļas salas nekas cits nebūtu, es būtu mierā ar to....

EdgarsK - nē. bet vai Tu kaut ko lietoji, rakstot pirmo postu? Tas ir tik atrauts no tēmas, ko autors rakstīja.... Bet nu saprotams, gadās arī tā :)

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.

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 - 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.

žēl 2 lati ?