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?

Ja raksts var būt tikai vienā tēmā un tēmas Tev tajā saitā ir parādītas kā dabūt (t.i. selekts kā dabūt apakškoku vienā rāvienā), tad kur ir problēma rakstus, kas droši vien ir citā tabulā, piejoinot klāt pie visām atrastajām tēmām?

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

Pie tam, ja raksti tēmas nemaina, tad koka elementiemvar iedot kādu nemainīgu idu, as nemainās arī tad, ja elementu kokā pārvieto, jo man liekas, ka šai modelī tikko veic elementu izmaiņas, tā citiem tas left un right arī var mainīties, attiecīgi tos kā atsauces izmantot nevar, jo tad raksti arī ceļos pa koku.

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ē. :)

hehe, tas gan ;)

bet tādi cilvēki arī pārāk nepievērsīs uzmanību tam tvnet paziņojumam un vnk pieradīs pie tā (un pie kā pierod, to pat nepamana :D). un turpinās tālāk lietot savu ie6, ja viņiem tā patiks, vai arī nav izvēles (kkādās iestādēs preinstalled software + useris pats neko nevar instalēt)

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 :)

nju par tvnet mums te jau nesen bija viena diskusija :D:D:D

http://php.lv/f/topic/15507-tvnet/

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

nju par tvnet mums te jau nesen bija viena diskusija :D:D:D

http://php.lv/f/topic/15507-tvnet/

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

Baidos, ka IE6 vēl izmanto pasaulē ~20% cilvēku kopumā! Tāpēc komerciālos projektos gluži nerēķināties ar IE6 lietotājiem nevar, bet ieteikt viņiem lejupielādēt labāku pārlūkprogrammu gan var!

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

ko juus tur '^@*^**^*' ar to bloku ?

Panjem table + JS fiksu prieks Old Brauzeriem (PNG transparentam, un ja izmanto GIF tad pat too nevajag ) un nostiilo ..

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.

btw, nemaz nebrīnītos, ja tgd atnāktu mefisto, pateiktu, ka man jāpamācās teorija un iemestu kādu linku :D

Bet tas jau ir labi. Mācīties, mācīties un vēlreiz mācīties... :D

Paldies par pieslēgšanos :)

Protams stūrīšu noapaļojumiem jābūt fona krāsā (lapas fona krāsā), ja uzliksi caurspīdīgus, tad ārējā div fona bilde būs redzama stūrīšos.

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.

pag, man ir ideja ar negative margin

varbūt sanāks, bet vēl taisu simple example...

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

Css:

#footer {
clear:both; 
bottom: 0;
}

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.

Vai tas ir domāts kā kaut kāds popups? Ja nē, tad kādēļ kaut ko pozicionēt absolūti?

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 :)

taisi vienk 3 divus, kur augšējā un apakšējā ir izgrieztas caurspīdīgas png bildes ar apaljuem stūriem un vidējā atkārtojas caurspīdīgs fons..

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.

Ja jau dalījums notiek pa PNG bildēm, tad kur problēma pieseivojot ieviest PNG alpha transparency?

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.

Ja gribi mega CSS, tad vari apaļos stūrus veidot arī ar border-radius (-moz-border-radius, -webkit-border-radius) propertiju, bet tā kā tas nav 100% atbalstīts, tad uz to nevar vienmēr paļauties (ja apmierina, ka, piemēram, daži (IE, Opera) apaļo stūru vietā redzēs neapaļus stūrus, tad dari tā).

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.

CKEditor + CKFinder

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?

Ieteiktu apskatīt CodeIgniter

Virsraksts iespārda! :D

CodeIgniter is an open source Web Application Framework that helps you write kick-ass PHP programs.

Bet jā, paldies! Ievērtēšu.

Nevis OOP vai func., bet MVC un citus programmēšnas paternus.

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.