Jump to content
php.lv forumi

bfj

Reģistrētie lietotāji
  • Posts

    29
  • Joined

  • Last visited

bfj's Achievements

Newbie

Newbie (1/14)

  1. 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.
  2. 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?
  3. 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.
  4. 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ē. :)
  5. 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 :)
  6. 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
  7. 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
  8. bfj

    JavaScript On/Off?

    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 :) ).
  9. Tieši tā ir izdarījis TVNET.
  10. bfj

    JavaScript On/Off?

    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?
  11. 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)?
  12. 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
  13. 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
  14. 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 :)
  15. 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...
×
×
  • Create New...