Grey_Wolf

Vispār palasam manuali ;) --- Handling Returns: It is possible to execute a return() statement inside an included file in order to terminate processing in that file and return to the script which called it. Also, it's possible to return values from included files. You can take the value of the include call as you would a normal function. This is not, however, possible when including remote files unless the output of the remote file has valid PHP start and end tags (as with any local file). You can declare the needed variables within those tags and they will be introduced at whichever point the file was included. Because include() is a special language construct, parentheses are not needed around its argument. Take care when comparing return value. -- Example #4 Comparing return value of include <?php // won't work, evaluated as include(('vars.php') == 'OK'), i.e. include('') if (include('vars.php') == 'OK') { echo 'OK'; } // works if ((include 'vars.php') == 'OK') { echo 'OK'; } ?> Example #5 include() and the return() statement return.php <?php $var = 'PHP'; return $var; ?> noreturn.php <?php $var = 'PHP'; ?> testreturns.php <?php $foo = include 'return.php'; echo $foo; // prints 'PHP' $bar = include 'noreturn.php'; echo $bar; // prints 1 ?> -- ši ficha jau ir no, kaa minimums, no PHP4 versijas (par 3 nezinu)

nu ja tiešām tās ir laika zīņas tad savādāk, bet starp require() un include() ir pāris stipri būtiskas atšķirības Ja nav ar require() izsaucamais fails, td buus fatal errors , include gadijumā tikai warning vel ir tāda atšķirība ka include var veikt Return() darbības. // Handling Returns: It is possible to execute a return() statement inside an included file in order to terminate processing in that file and return to the script which called it. Also, it's possible to return values from included files. You can take the value of the include call as you would a normal function. This is not, however, possible when including remote files unless the output of the remote file has valid PHP start and end tags (as with any local file). You can declare the needed variables within those tags and they will be introduced at whichever point the file was included. // reguire() to nepieļauj ---

90% gadijumu vispār Nekādi IF un cikli etc. HTML kodā nav nepieciešami. izmanto templetu endžinu vai nē, tāpat ir redzams ka kods nav īsti loģisks. Ja jaizvada 2 bloki tad katrā gadijumā to var izdarīt svādāk. Kut vai katram ielādēt atsevišķu failu -- šo arī var parkstīt savādāk <?php if ($first_page !== FALSE): ?><a href="<?php echo $page->url($first_page) ?>" rel="first"><?php echo __('First') ?></a><?php else: echo __('First'); endif ?> <?php if ($first_page !== FALSE){ $izvade='<a href="'.$page->url($first_page)'." rel="first">'. __('First').'</a>'; else{ $izvade= __('First'); } ?> Html .... <?php echo $izvade; ?> Man personīgi šādi ir krietni ērtāk lasīt un arī jebkuram svešam koderim būs saprotamāk -> atliks tikai sameklēt kur definēts $izvade (kaut vai 'izbraucot' , ar kādu failu pārlūku, cauri visiem projekta failiem ... un dizainerim jau nu pastāstīt ka dotajā vietā jāraksta $izvade ir elementārāk kā likt uzrakstīt to templeta pseido kodu

Kur problēma? Table zināmos gadijumos ir Ok. it īpaši ja dati ir strukturēti tabulā- tad to tabulu ģenerēt no <div> ir diezgan pastūlbi.

Pilnīgas muļķības, ja kodu liek iekšā programmētājs, tad dizainerim visāpār ar to nav nekāda sakara. Tur pretī ja dizaineris liek iekšā tos templetu simbolus etc. , tad vieglāk viņam iemācīt PHP pamatus. Piedevām templetu sistēma noēd daļu no resursiem. Kods vispār jastrukturē tā, lai pēc iespējas mazāk HTML daļa būtu PHP konstrukcijas - tikai tīras datu izvades un nekas vairāk .. 99% gadījumos nav nepieciešams HTML kodā daļa izmantot IF/FALSE vai vel trakāk ciklus. Vienkārši jaizmanto MVC principus, nav jau jāpieturās pilnīgi pie viņiem, tomēr PHP daļu maksimāli būtu jādala no HTML

90% vācijā tapuši kodi būs Vāciski. protams ja tie nav domāti globālajam tirgum, bet visi iekšējai lietošanai būs vāciski. P.S. pat esmu redzējis Vācijā pasūtītu kodu (lielā starptautiskā firmā), kas veidos pamatā vāciski, neskatoties ka pasūtītājs nebūt nebija no vācijas.

nee caurspidīgums, Alpha kanls norada uz caurspīdigumu, tur varuzlikt arī daļēju - puscaurspīdīgu, ta ari jādara kamēr pieregulē atrašanās vietu. Jo šjā gadījumā elements ir pilnībā aktīvs, ieskaitot ka aizņem tam paredzēto vietu etc., bet tikai caurspīdīgs. ne vienmēr tas der, jo ja prasīgs klients atsūtīs dizainu, tad nekādi pašdarbības gājieni neies cauri ... (būs klients, kas skaidri norādīs, ka visam jāstrādā arī uz IE6, un stāstīt ka tas nav forši ir bezcerīgi, atbilde būs: - nevari? Atradīšu kas var/māk. Piedevām kad saprot ideju, uztaisīt ir pilnīgi elementāri, tik cik pāris rindiņas kodā.

1. kur ir tam file inputam CSS ? 2. kur ir lauka pozicionēšna 3. kur ir JS funkcija? 4. kāpēc pirms onchange pēdiņam ir slash (kas viņs likvidē) 5. tai tavai veidotaja poga ir jābūt ZEM īstās brofse pogas, (tādēļ jau tiek izmantos Positin: absalute un tie z-indexi ) reāli jau tiek spiests uz ISTĀS pogas, nevis uz tava lauka, kas tikai uzlikts smukumam, jo īstā poga ir NEREDZMA .

Ja gribi tam failu upldam smuku dizainu, tad ir samērā hitrs risinajums. Tam input file laukm ir jaabuut, bet viņs var būt CAURSPĪDĪGS ;) 1. tatad izveidojm <input type="file" name="xxxxxx" id="fails" onchange="paraadit(this.id,'id_2')"> , un nopozicionējam ar position: absalute, un norādam kurā slānī viņam but [ z-index: 999 ] 2. CSS uzliekam šādus atribūtus -moz-opacity:0 ; filter:alpha(opacity: 0); opacity: 0; tas ir padaram vīņu neredzmu 3. ZEM tā brofse butona izveideojam nepiecīešmo zīmējumu, vai jabkuru zitu dizaina elementu (pogu pēc izskatā kādu vēlies) un nopozicinējam viņu ar position:absalute tieši zem brofse pogas ( izmantojot z-index:888) [vismaz 1 līmeni zemak nekā input laukam] 4. zem vile input teksta laucīņa , izveidojam parastu input type="text" ar id="id_2" lauku, (protams position absalute...) 5. izveidojam JS funkciju paraadit() function paradit(id_x) { var kas=document.getElementById(id,id_2).value; document.getElementById(id_2).value=kas; return false; } -- tātad visam šmam murgam domai ir: a) noslēp to file ievades lauku, bet atstāt vīņu aktīvu. b) tad kad useris ir izvēlējies vajadzīgo faila ceļu , parādīt to userim -- šāda shema strādā gandrīz uz visiem brauzeriem pats esmu testējis IE6- IE8 Opera, Firefox, Safari --- P.S. lielākā problema ir tā ka katram brauzerim tā poga 'brofse' ir atšķirīgos lielumos :( Edit: Inputs ir VIRSU, nevis apakšā. savādāk uz viņa nevarēs uzklikot, attiecīgi atvērt meklēšanas logu ...

Labs ;) Vispār, tā sākt kļūt par drūmu patiesību. Kaut gan kā jau minēju, ja projekts latvisks, tad šur tur var pagrēkot un kādu funkciju arī 'nolamāt' latviski. piem. function funkcija1234($a999){ .... xxx } // vai tomēr function funkcija_atgriezj_gatavu_izvelni($izvelnes_masivs){ ....xxx } Un ja tā filozofiski paskatās, tad tie angliskie termini arī ir diezgan ņirdzīgi, pierasti, bet ņirdzīgi. Jo īsti jau nav tīru kompjuter terminu, pārsvarā visi ir atvasinājumi no ikdienā lietojamiem vārdiem.

Nēsi nekad saticies ar Deutschland programeriem :( Tur PILNIGI VISS ir vāciski ... , kur problēma, ja projekts ir priekš Latvijas? Kāpēc būtu viss jāraksta Angliski? Daudzmaz starptautiskā projēktā -> Ok. saprotams, bet lokāli? Kur problēma? edit: nu ir zināmas problemas ja NickName nosauc par palamu -> tur piekritīšu - bet komenti, + funkciju nosaukumi ( ja protams tie ir uz reiz saprotami), Nu neredzu probzas, ja vel ir daudzmaz normāli komenti

abos tavos piemēros ir neliela kļūda, uz vecām JS versijām būs kļūdas ziņojums, VAI kods vienkārši neizpildīsies :( Par to arī šis stāsts. --- Vispār jau pajautāju @rATRIJS kāpēc viņuprāt izmantot new array() ir Slikti (nevis nedrīkst, bet tieši kāpēc tā nedarīt). -- P.S. Flame OFF. Negribu reliģiskos strīdus ...( un nav īpašas jēgas arī, kopā [vismaz foruma ietvaros] jādzīvo )

nē , es tieši gribēju uzsvērt, ka izmantot tā var, bet nebūt tas nav labi ... --- P.S. domāju ka topiks aizgājis jau reliģiskos strīdos :(

WTF? JS ja mainīgais ir definēts ārpus funkcijas (vienkārši kodā) tad viņš ir globāls, ar VAR vai bez. Un pēkšņi funkcijas iekšienē definēt Globālu mainīgo - gribi teikt ka tas ir labs stils? jebšu pašā kodā mainīgos definē bez VAR? -- Piedevām to minēju, kā piemēru ka tā var definēt, bet tas tiešām nav labi.

visos pārlūkos kas būtu jāatbalsta var mierīgi neizmantot arī VAR pirms mainīgā, kā arī pieļaut daudz citu sīku koda nepilnību. tas nenozīmē ka tā ir LABĀK. -- īstenībā nesaņēmu nevienu PILNĪBĀ PAMATOTU argumentu kādēļ tā darīt ir slikti. (tieši slikti, nevis labāk/sliktāk)

1.tas ka kods ir īsāks nav arguments, jo īsāks kods nevienmēr nozīmē vieglāk uztverams. 2. tas nav lasāmaks, jo nekad nevarēsi būt 100% pārliecinats ka tas tiešam ir jauns masīvs, nevis papildinājums 3. tas ka iekš JSON neredzēšu funkciju kas veido JAUNU masīvu - manuprāt ļoti bērnišķigs arguments, jo tur neredzēšu arī norādi ka tas ir mainīgais ( VAR ), vai objekts. 4. 90% citu kodos tieši pretēji redzēšu NEW array() -> jo tas ir savietojams ar VISAM JS versijām, arī vecām .. 5. to ko saka viens cilvēks, nevienmēr japieņem par labu esam, jo Bils Geits ~'80 paziņoja visai pasaule "640Kb RAM pietikšot pilnīgi visām aplikācijām", kā zināms viņam šo paziņojumu nācās nožēlot (vel tagat par to ņirgājās)

1. without boom, norāda ka dokumenta sākumā netiks pievienota info, ka tas ir UTF-8 , un neko vairāk. (3 simboli) 2. sen izrunāta problēma pēc konekcijas pie DB mysql_query("SET NAMES UTF8"); 3. pārliecinies ka HTML haiderī tiek norādīts pareizs kodējums.

dotaja piemērā, jā vajag stiept līdzi milzīgo jqurey bbliotēku, bet to var arī nedarīt document.getElementById('konteneris').innerHTML ="<img src='" + galerija[0] + "'/>"; @rATRIJS Lūdzu pamato kādēļ normāli definējot masīvu, tas nav smuki ?

tieši tā.

Par stabīlajām vers. pilnībā piekritu, bet ne par pēdējām. Jo, ja taisi priekš sevīm ir Ok. , bet ta 90% gadijumos klientam nebūs tās pēdējās versijas. Tas gan attiecās, ja izmanto jaunākās fīčas. Manuprāt šobrīd optimāli ir izmantot 5.2 + , jo šai versijai bija diezgan daudz būtiski jaunievedumi.

vispār jau cena tiem domēniem plānojas vājpr'tīga, un atļauties varēs vien lielās kompānijas. Piedevām privātpersonas vispār shamos nevarēs iegūt. P.S. būtu fiksi janodibina firmele "SEX" ;)

iespējams ka win XP normāli nesoportē kādu no taviem dzelžiem a) parāk liels RAM - WIN XP max suportee 3Gb b) Pārāk liels HDD, vai arī uz HDD ir daudz bad bloku, c) C: nav fiziski pieslegts kaa primary. (tieši pei mātenes) d) HDD slikti sadzīvo ar CD/DVD, reti bet šāda problēma ir, parasti XP pamatīgi gļučī. [ dažu firmu CD slikti sadzivo ar citu firmu HDD - ja atrodās uz vienas jostas ] d) beigts RAM. Jaunajiem RAM ir iebūvēta iespēja izmantot rezerves šūnas - pārslegties no bojatajiem elementiem, uz veseljiem, diemžēl WIN XP to pie ielādes neakceptē e) tiek izmantoti dažādu firmu RAM uz paralēlajiem portiem (1-2 3-4 ) piemeram uz 1 un 2 porta atrodas dažadu firmu vai nominālu RAM f) ja ir papildus fiziskais HDD tad ieteiktu vinjam uzrīdīt virsu diskskanu - nezinu kāda X pēc, bet XP nepatīk ja otrs fiziskais disks ģļučī, pat līdz iespējai, ka vispār nestartējās - 99,9% gadijumos palīdz ja ieliek citā kompī un vienkārši piestartē Windu un uzrida DiskScanu.

Kāds sakars WIN ar PHP?

Viss kas tev vjadzīgs ir izvilkt 1 ierakstu randomaa izmanto SQL f-ju RAND() SELECT id, img, links, 'parejie vajadzigie lauki' FROM `table` ORDER BY RAND() LIMIT 0,1;

Izmantojot cikla skaitītāju tieši 'putru' var novērst, jo: 1. zināsi kurā brīdī parādās kļūda - reāli cik daudz tagu tika apstrādāts 2. atsevišķiem tāgiem taču var pielikt tāga nosaukumu - piem: "kategorija_1_99999n", "subkategorija_10_99999n". 3. zināsi precīzi cik daudz datu ir - nevis pēc apjoma Mb, bet pēc skaita Piedevām šādu 'datu ģenerātoru', prātīgāk ir rakstīt kāda citā valodā , kaut vai paskālā. P.S. Vari uzrakstīt algoritmu, un palūgt lai kāds zinošāks, pārnes šamo uz paskālu/c++ etc..