bfj

Ja kodē Symfony PHP ietvarā, izmantojot Propel ORMu tad labāk izskatās, ja tabulu nosaukumi ir vienskaitlī. Jo Propel piedāvā uzģenerēt modeli tabulu klasēm un metodēm, ņemot vērā DB struktūru. Tad, piemēram: UserPeer::getUser() vienas rindas atlasei, UserPeer::getUsers() vairāku rindu atlasei. Bet vispār pa lielam jau tas ir sīkums, kamēr viena projekta ietvaros turies pie viena principa.

Kāda tabula satur lauku 'type', kas tiek izmantots, lai grupētu tabulas ierakstus konkrētās grupās. Tabula var saturēt, piemēram lietotājus, kādus ziņu rakstus utml. Uzskatāmības un saprotamības labad programmā tiek ieviestas konstantes atbilstošajiem tipiem ('type' vērtībām) - tas PHP valodā, kādā C# tas varētu būt ENUM. Papildus varbūt arī var ieviest konstantes ar atbilstošiem tipu nosaukumiem (ja tie kaut kur jārāda lietotājam - teiksim, dropdownā). Vai nepieciešams ieviest atsevišķu tabulu, kur glabājas atbilstošie tipi, uz kuriem referencējas jau minētais 'type' lauks? Būtībā, tam ir savi plusi, teiksim integritātes ziņā - atliek izdzēst tipu iekš DB un tiek izdzēsti atbilstošie ieraksti ar dzēsto tipu. Bet priekš kam atkārtoties, ja jebkurā gadījumā ieraksti pašā programmā tiek klasificēti pēc to tipiem un būtībā nekādu citu funkciju lauks 'type' nepilda. Būtu interesanti uzzināt arī viedokli par pretēju gadījumu. Ir tabula ar tipiem, uz kuru referencējas lauks 'type' - vai būtu jāievieš konstantes? Tad nebūtu visur jāraksta, piemēram "if($type == 1)...", bet būtu daudz skaidrāk "if($type == KAUT_KAADS_IERAKSTA_TIPS)..." Protams, lielā mērā tas atkarīgs no konkrētās situācijas un nepieciešamās funkcionalitātes, bet... Kā šī foruma web programmēšanas guru risina šīs problēmas? Vai tā ir gaumes/stila preference vai ir kādi citi ieguvumi/zaudējumi?

Tātad - rakstam ir atslēga uz 'tēmas_id' un selekts varētu būt aptuveni šāds? SELECT * FROM raksti JOIN tēmas ON raksti.tēmas_id = tēmas.id WHERE tēmas.lft > tēmu_parent_lft AND tēmas.rgt < tēmu_parent_rgt Nu - šis nemainīgais ID ir tēmas ID. Un tieši tā, pie jebkurām koka izmaiņām jāpārrēķina left un right vērtības. Vispār diezgan loģiski, jo tas pasargātu no tādiem brīnumiem kā, piemēram, tēma ir raksta bērns.

Sveicināti! Problēma ir sekojoša - nepieciešams izveidot hierarhisku struktūru vairākiem objektiem. Piemēram - tēma (var būt iekš citas tēmas), raksts utt... Iespaidojos no šī raksta un veidoju hierarhiju koka veidā katram objektam piesaistot kreisās un labās puses numurus. Viss ir skaisti līdz brīdim, kamēr hierarhiski jāatlasa dažāda veida objekti. Minētajā piemērā ar tēmām nav problēmu, taču, kā lai atlasa tēmas + rakstus hierarhiskai attēlošanai? Protams, pirmais, kas nāk prātā - kokā ir tikai tēmas, atlasam koku, ejam cauri katram koka elementam un atrodam atbilstošos rakstus, bet tad jāizpilda vairāki vaicājumi ar identisku uzbūvi, un gribētos atrast kādu efektīvāku pieeju. Respektīvi - gribētos to visu realizēt ar pēc iespējas minimālu vaicājumu skaitu un programatisku datu apstaigāšanu. Varbūt varētu ieviest atsevišķu tabulu, kurā reprezentēts koks (id, nr_kreisajā pusē, nr_labajā_pusē) un atbilstošajās tēmu un rakstu tabulās pievienot saiti uz koka tabulas atbilstošo rindu? Varbūt būtu kāds vēl efektīvāks veids? Gan jau kādam šeit ir nācies saskarties ar ko līdzīgu, tādēļ krītu ceļos un lūdzu padalīties pieredzē. :)

Nu tādā gadījumā vajag milzīgu sarkanu popup loga centrā, kas ir puse no lapas izmēriem :D Par otru gadījumu gan fakts. Un jau atkal nikns skatiens "mikromīkstā giganta" virzienā, ka neseko vienotiem standartiem, bet izvirza paši savus :)

Nu jā, bet, manuprāt, tas, ka TVNET izmet brīdinājumu, ir samērā sakarīgs risinājums. Jo vairāk webā samazināsies IE6 atbalsts, jo vairāk nomigrēs viens, otrs, nākamais lietotājs (ja nu galīgi nemācēs uzlikt jaunu pārlūkprogrammu, tad gan jau atradīs kādu palīgu) un beigās gan developeri būs laimīgi, gan lietotāji apmierināti. Cilvēkiem tiek barots, ka IE6 ir slikts. Un jau tagad liela daļa, kas uzskata, ka internets ir pati pārlūkprogramma, saka, ka FF esot labāks internets, nekā IE :D

Nu jā, bet, manuprāt, tas, ka TVNET izmet brīdinājumu, ir samērā sakarīgs risinājums. Cilvēkiem tiek barots, ka IE6 ir slikts. Un jau tagad liela daļa, kas uzskata, ka internets ir pati pārlūkprogramma, saka, ka FF esot labāks internets, nekā IE :D

Bet, teiksim, kādas dizaina īpatnības, kur bez JS nu nekādi nevar? Piemēram, nav "tīra" CSS risinājuma, lai IE6 atbalstītu caurspīdīgus PNG attēlus) - protams, var mēģināt iztikt ar GIF, bet tas reizēm izskatās vēl drausmīgāk. Šajā gadījumā gan tekstuālā informācija lapā ir pieejama, bet tas var izskatīties arī baisi un nepārskatāmi (protams, var meklēt citus dizaina risinājumus, bet pasūtītājs reizēm mēdz būt ļoti uzstājīgs :) ).

Tieši tā ir izdarījis TVNET.

Vienmēr ir bijis slinkums un noņemšanās veidot alternatīvu funkcionalitāti gadījumiem, ja JavaScript klienta pusē ir izslēgts. Tomēr nu jau tagad, manuprāt, ir neiespējami (varbūt kāds tomēr zin?) atrast kādu mūsdienīgu pārlūku, kas neatbalstītu JavaScript (pat manā 2-3 gadus vecā un lētā Sony Ericsson telefona pārlūkā ir JavaScript atbalsts), tādēļ pat sāku pieļaut, ka varbūt aiztaupīt jau tā dārgo laiku un neparedzēt gadījumus, kad lietotājs varētu būt izslēdzis JavaScript? Tad nu šajā sakarā arī vēlos uzzināt citu domas. Vai vienmēr tiek piedomāts pie tā, lai lietotājs ar izslēgtu JavaScript var veikt tās pašas darbības, kuras var veikt ar ieslēgtu JavaScript?

IE6 lietotāju skaits nebeidz samazināties (tas priecē, ne?). Google drīz griezīs nost IE6 atbalstu savās aplikācijās, šeit pie mums arī TVNET nepiedāvā pilnu portāla funkcionalitāti, ja tas tiek pārlūkots ar IE6. Ir vēl daudz citu piemēru, kas liecina, ka IE6 tiek lēnām izskausts (spiežam šeit). Nesen sanāca vienoties ar pasūtītāju par IE6 atbalsta neiekļaušanu, par ko sapriecājos ne pa jokam :) Tad nu vēlējos uzzināt kā šī foruma lietotāji uz to visu skatās. Vai īstenojot projektus vairs nedomājat par IE6 vai tomēr vēl rūpīgi testējat savu veikumu uz šī pārlūka (protams, izņemot, piemēram iekšējas uzņēmuma sistēmas, kas mistisku iemeslu dēļ izveidotas tā, ka normāli strādā tikai ar IE6)?

Mhm, IE7 ir viss kārtībā. Gan žēl, ka IE6 jāizmanto 'expression' un 'behaviour', taču ko citu padarīsi, turklāt, tam, kurš šajos laikos lietos IE6, diez vai būs vajadzība vai zināšanas kā atslēgt JS :D Ceru, ka neizraisīšu kārtējo 'table' vs. 'div' grautiņu, bet... Tabulas NAV priekš izkārtojuma!!!! Punkts!! :D

Oh my god! Super, Tu esi mani izglābis! :) Starp citu, tieši šādu variantu (izņemot Tavu IE6 maģiju) ar 'top' un 'bottom' vērtībām jau biju mēģinājis, taču nekādi nebiju iedomājies, ka bez 'height' propertija un ar vienlacīgi uzstādītām 'top' un 'bottom' vērtībām vidus pats stieptos. Bet tas jau ir labi. Mācīties, mācīties un vēlreiz mācīties... :D

Paldies par pieslēgšanos :) Lūk, tieši tā arī ir problēma. Lapai fons ir raibs un jebkurā gadījumā vēlos panākt to, lai bloku varētu novietot jebkur, neatkarīgi no fona. Lai stūru apaļojumi būtu caurspīdīgi, tāpat arī pats bloks. Jau biju mēģinājis arī līdzīgu metodi, kā Tu aprakstīji. Un, izmantojot šo metodi, ja augšas un apakšas bildes ir caurspīdīgas, tad jebkurā gadījumā satura fons būs redzams zem augšas un apakšas bildēm un 'z-index' īsti nepalīdzēs. To es arī izmēģinājos visdažādākajos variantos. Ceru, ka Tev izdosies :)

Vai tiešām kādam nebūtu idejas vai pieredze ar šādu situāciju? Protams, apzinos, ka nav jau neviena pienākums palīdzēt, bet jau sākās izmisums. :) Ļoti negribētos klientam teikt, ka būs jāiztiek ar necaurspīdīgiem blokiem vai arī jāizmanto JavaScript...

No šī būtībā nav nekādas jēgas, ja Tu footeri nepozicionē vai neliec float. Un vēl jautājums, vai Tu gribi, lai footeris ir lapas apakšā (un zem satura bloka, ja tā augstums ir garāks par browsera loga augstumu) vai tikai pēc satura bloka? Ja Tu parādītu kodu satura blokam virs footera, tad varētu kaut ko apskatīties, bet vispār: Sticky footer #1, Sticky footer #2 un protams iekš google - sticky footer.

To es biju tajā brīdī ieņēmis galvā, kad jau kādu n-to reizi mēģināju sasniegt rezultātu :) Tas nav kā popups. Mēģināju absolūti pozicionēt backgroundus iekš paša bloka. Zemāk pagaidām tuvākais rezultāts, kādu man izdevies sasniegt. Kā redzams, tad vidus pārklājas ar apakšu, turklāt, paliek vieta vēl zem teksta (protams, reāli būs atkāpes no malām, taču, manuprāt tas īsti nemaina lietas būtību, jo gribētos izveidot kopēju principu, kuru varētu lietot arī pārējiem blokiem - tādi ir vairāki un ar savādāk noapaļotiem stūriem un slīpām malām - šis piemērs būtu "neapaļākais" no tiem, kurus vēl vajadzēs veidot). HTML: <div id="wrapper"> <div class="bg_top"><div class="bg_middle"><div class="bg_bottom"> <div class="content"> Lorem ipsum dolor sit amet... <!--Īsuma labad, tikai nedaudz teksta--> </div> </div></div></div> </div> CSS: #wrapper { float: right; width: 732px; margin: 9px 36px 0 0; } .bg_top, .bg_middle, .bg_bottom { float: left; width: 100%; } .bg_top { background-image: url(../images/bg_menu_t.png); background-repeat: no-repeat; background-position:0 0; } .bg_middle { background-image: url(../images/bg_menu_m.png); background-repeat: repeat-y; background-position:0 0; position: relative; top: 18px; } .bg_bottom { background-image: url(../images/bg_menu_b.png); background-repeat: no-repeat; background-position:0 100%; } #wrapper .content { position: relative; top: -18px; min-height: 47px; } P.S. Koda lasāmību un sakārtotību var neņemt vērā. Tāpat arī neesmu iekopējis atsevišķos IE6 CSS, kur izlaboti 'Double margin bug' un PNG atbalsts. Šobrīd tikai jāsasniedz vēlamais. Pēc tam varēs tīrīt :)

Un kā panākt, lai vidējais divs stiepjas līdzi saturam (un reizē nepārklājas ar augšu un/vai apakšu)? Augšai un apakšai ir fiksēts augstums, bet vidu vajag dinamisku un saturam jābūt no pašas bloka augšas līdz apakšai, t.i. nevar būt tā, ka saturs ir zem augšējā diva un virs apakšējā diva.

Tā jau arī daru, bet... Laikam būšu ne pārāk pareizi noformējis problēmu (ko var gribēt plkst. 3:00 naktī :) ). Kā panākt, lai dalītie posmi nepārklājas? Ja PNG nav caurspīdīgi, tad to bez problēmām var izdarīt, izmantojot 'z-index' un/vai citus jau zināmus brīnumus, taču šajā gadījumā, vajag, lai bloka fons ir caurspīdīgs. Teiksim, to var uztaisīt absolūti pozicionējot bildes daļas, vidus bildei nosakot 'top' vērtību no augšas un apakšai 'bottom:0', bet vidum vajadzētu stiepties līdz ar saturu (šajā gadījumā, tātad 100% augstums nederēs, jo vidus pārklāsies pāri apakšai). Tā kā augšai un apakšai būtu fiksēts augstums, vidum būtu jāstiepjas, bet bloka saturam vajadzētu sākties un beigties nevis līdz ar vidusposmu, bet bloka augšu un apakšu. Kaut ko tādu arī apsvēru, taču laikam būs vien jāgaida, kamēr CSS3 kļūs par standartu un cilvēki vairs nelietos (naivi gan :D) IE6 un 7

Sveicināti! Kā varētu dabūt gatavu caurspīdīgu bloku ar apaļiem stūriem? Jāņem vērā, ka tā katrs stūris apaļots savādāk un tā malas nav taisnas. Blokam būtu jāstiepjas vertikāli, atkarībā no tā satura (platums var būt fiksēts). To varētu realizēt, sadalot bloka fona .png bildi trīs daļās - augša, vidus (vertikāli atkārtojas) un apakša, ko nav problemātiski uztaisīt, taču - kā lai to visu padara caurspīdīgu? Caurspīdīgam jābūt tikai fonam, pats saturs nedrīkst būt caurspīdīgs, tā kā CSS 'opacity', manuprāt šeit īsti nederēs. Pieļauju, ka to var realizēt ar JavaScript palīdzību, taču tas būtu samērā nevēlami. Ideāli būtu tīrs CSS risinājums. Te tāds aptuvens piemērs: Būšu pateicīgs par jebkādu ideju. P.S. Protams, tam visam vajadzētu būt 'cross-browser compatible'

Paldies! Ieteikumi baigi ok. Papētīšu sīkāk. Gan sāku domāt, varbūt izmantot YUI 2, kas apvieno daudz jēdzīgu lietu un varētu noderēt arī citām funkcijām + vēl arī klāt ir RichText redaktors un tad likt upload formas bildēm un video atsevišķi, piedāvāt lietotājam kopēt URLus un embed kodus vai kkā tamlīdzīgi, jo YUI RichText var atrast plaginu, kas piedāvā embedēt. Bet tā tikai ideja. CKFinder ir tikai par maksu.

Domāju, ka šis jautājums te iederas :) Vai ir kāds redaktors, kam par brīvu pieejami failu menedžeri vai vismaz upload funkcija bildēm un video (.flv)? TinyMCE un CKEditor ir perfekti, taču minētās funkcijas ļoti pietrūkst (ir pieejamas, bet tikai par maksu). Problēma tāda, ka bildes un video var ievietot, tikai norādot URL, bet manā gadījumā būtu perfekti, ja pie teksta rediģēšanas lietotājs varētu apskatīt jau esošos failus vai vismaz uploadot jaunu. Esmu lietojis freeRichTextEditor. Samērā perfekts manām vajadzībām un tam it kā varētu pats tādu funkcionalitāti pielikt, jo source ir vienkārša un saprotama, taču ir maz laika eksperimentēt (lai gan interesē :) ). Kādam ir kādas idejas?

Virsraksts iespārda! :D Bet jā, paldies! Ievērtēšu.

Runājot par MVC u.c. Veidojat paši savus tā teikt "freimworkus" vai izmantojat gatavus? Pagaidām nejūtos tik spēcīgs (un laika jau arī nav :) ), lai veidotu pats savu, tādēļ plānoju nedaudz iemest aci jau gatavos freimworkos. Kādus Jūs ieteiktu apskatīt? Zend? CakePHP?

Sveicināti! Kādu pieeju iekš PHP izvēlēties - OOP vai funkcionālo programmēšanu? Runā, ka OOP ir lielākas priekšrocības (koda izmantojamība un sakārtotība, vieglāk atrast kļūdas utt. un tā joprojām), tomēr, izmantojot funkcijas + masīvus + include failus varu sasniegt faktiski tādu pašu rezultātu, turklāt daudz ātrāk (vienīgi kļūdu labošanas process ir nedaudz sarežģītāks). Vēl gan arī jāņem vērā, ka tas var būt arī atkarīgs no projekta sarežģītības un apjoma, taču šis jautājums vairāk interesē vispārināti. Esmu lasījies apkārt dažādos forumos, taču nekur tā arī nav skaidru un konkrētu piemēru, kāpēc viena pieeja būtu labāka par otru un otrādi. Kaut vai piemēram, kā tas atsauktos uz ātrdarbību. Ko domā lielie PHP guru šajā forumā? Vai tas vairāk ir gaumes jautājums vai arī tomēr ir kādi konkrēti argumenti, kādēļ darīt tā un ne savādāk.