tas_pats
-
Posts
52 -
Joined
-
Last visited
Everything posted by tas_pats
-
Ko tu mēģināji paveikt un kas tieši tev nesanāca ?
-
Pirms ievietošanas datubāzē noteikti apstrādā ar mysql_real_escape_string Pēc tam izvadot no db dabūto tekstu html struktūrā izmantoju htmlspecialchars.
-
Tak izsakies skaidrāk. Ko tu gribi izdarīt ? No tā, ko tu uzrakstīji, neko nevar saprast.
-
Tātad tur ir pavisam jocīgi definēts: <dateFormats> <dateFormatLength type="full"> <dateFormat> <pattern>EEEE, y. 'gada' d. MMMM</pattern> </dateFormat> </dateFormatLength> <dateFormatLength type="long"> <dateFormat> <pattern>y. 'gada' d. MMMM</pattern> </dateFormat> </dateFormatLength> <dateFormatLength type="medium"> <dateFormat> <pattern>y. 'gada' d. MMM</pattern> </dateFormat> </dateFormatLength> <dateFormatLength type="short"> <dateFormat> <pattern>dd.MM.yy</pattern> </dateFormat> </dateFormatLength> </dateFormats>
-
Uzraku šitādu projektu: CLDR - Unicode Common Locale Data Repository. Tur Latvijas lokālei arī datums ir norādīts formātā dd.MM.yy
-
Jā, bet pareizajam formātam tad kautkur būtu jābūt rakstītam/atzīmētam - ja reiz pat skolā balli novelk nost. Pagaidam neesmu atradis neko internetā izvietotu.
-
Vienmēr esmu lietojis dd.mm.yyyy formātu, taču skatos, ka citur oficiālos dokumentos (piemēram pasē) datums ir dd.mm.yyyy. formātā (ar punktu galā). Un man ir uznākusi ziņkāre kāds tad ir Latvijā oficiāli pieņemtais (vai varbūt standartizētais?) datuma formāts. Sāku meklēties googlē, bet tā arī neko pagaidām neesmu atradis. Kā tad īsti ir ? Un kur varētu aplūkot arī citus līdzīgus nacionālos standartus?
-
<head> blokā ievieto: <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> pārliecinies vai pats fails ir utf-8 kodējumā.
-
Bezmaksas e-commerce aplikāciju apkopojums
-
Ei, liels paldies Tev Aleksej - works like a charm!
-
tas bija pirmais, ko iedomājos, taču tādā veidā netiks atlasīti tie ieraksti kam datums ir mazāks, taču id lielāks.
-
Kā ierakstam atrast nākamo un iepriekšējo ierakstu, ja atlasei ir vairāki kārtošanas parametri ? Teiksim, man ir tabula documents ar laukiem id,name,date . Dokumenti tiek atlasīti dilstoši vispirms pēc datuma, pēc tam pēc id: SELECT name FROM documents WHERE id = x ORDER BY date DESC, id DESC Kad man ir atvērts dokumenta skats man vajag saites uz nākamo un iepriekšējo dokumentu. Ja tiktu kārtots pēc viena parametra tad būtu vienkārši atrast: SELECT name FROM documents WHERE date > xxx ORDER BY date DESC LIMIT 1 Taču patlaban vainu galva nestrādā vai galīgi nevaru izdomāt kā atlasīt nākamo vai iepriekšējo, ja kārtots tiek pēc vairākiem laukiem.
-
Statiskam saturam tavs risinājums derēs ļoti labi, taču šajā gadījumā šķiet runa ir par dinamisku satura tulkojumu struktūru.
-
Nepiekrītu.. Viens no ietvaru galvenajiem mērķiem ir paātrināt programmatūras izstrādes procesu. Jo vairāk ierobežojumi, kam jāpiemērojas, jo vairāk tie samazinās izstrādes procesa ātrumu un vietām tie arī ierobežo aplikācijas elastību. Tāpēc, manuprāt, daudz labāk ir definēt vadlīnijas, kuras ieviešot un pie kurām pieturoties tu saproti to jēgu un jūti to devumu. Teiksim, pašos pirmsākumos, kad līdz ar šī ietvara apguvi, mēģināju apgūt arī MVC modeli. No sākuma neizpratu Modeļu (models) jēgu un būtību, tāpēc rakstīju (un CodeIgniter nespieda mani to darīt) visus vaicājumus kontroleros, nevis modeļos, līdz sapratu cik pārskatāmāku un lasāmāku kodu to izmantojot var iegūt. P.S. protams viss atkarīgs no tā ko katrs no mums saprot ar terminu "strikti ierobežojumi"
-
Jau kādu laiku lietoju CodeIgniter, ātri apgūstams un neuzspiež striktus nosacījums. Nezinu kā ir patreiz (kā pārējie ietvari attīstījušies), bet kādreiz tas arī skaitījās ātrākais.
-
php.lv RSS barotnē pēdējās ziņas ir no šī gada februāra. Vai varētu to sataisīt? Jo savādāk šai opcijai nav īsti jēgas.
-
Gribētu noskaidrot kā jūs rīkojaties ar datumu apstrādi glabāšanai mysql tabulās. Kā labāk rīkoties konvertēt datumu PHP pusē uz mysql DATE vai DATETIME formātu, vai arī konvertāciju atstāt MYSQL ziņā izmantojot FROM_UNIXTIME funkciju, vai vienkārši glabājat UNIX TIMESTAMP vērtību kā int lauku. Varbūt ir vēl kāda interesanta metode. Kādas būtu katras metodes priekšrocības vai trūkumi? Kā jūsuprāt būtu rīkoties pareizāk ?
-
Vai šī regex izteiksme būs korekta pozitīvu decimālskaitļu pārbaudei? /^(\d*)(\.?)(\d*)$/
-
Sakontaktējos ar hostingu un jau vakar tika uzinstalēts fileinfo modulis, bet paldies tev Klez par atsaucību.
-
Laikam būs jākontaktējās vien ar hostu.
-
Mēģināju noteikt audio faila mime tipu ar mime_content_type() un finfo_file(), bet izrādās, ka uz hosta nav uzinstalēti magic_mime un fileinfo moduļi. Vai ir vēl kāds drošs veids kā noskaidrot faila mime tipu?
-
Pie viena es gribētu pavaicāt vai nav kāds labs risinājums izdomāts kirlica burtu pārveidošanai uz latīņu burtiem ?
-
Sveiki, man ir mysql datubāze ar divām tabulām: tabula1: id param_name tabula2: id param_id1 param_id2 param_id3 es nevaru izdomāt kā piesaistīt tabula2 tabulai katram parametru laukam nosaukumu (param_name) no tabulas tabula1. Ceru, ka sapratāt manu domu.
-
Vai ir kāds toolis, ar ko varētu nokonvertēt veselu direktoriju? Jo tas nav mans projekts.. un negribētos gluži pārsimts failiem ar roku mainīt kodējumu, jo kā izrādās tie ir kā nu kurais katrs ar savu kodējumu..
-
Tātad pārvietojot lapu no Windows servera (kur tā griezās izmantojot XAMPP) uz unix kastes (nano.lv, bet pieņemu, ka nozīmes tur nav) un sākas problēmas - tekstā, kurš iekš DB tiek glabāts utf8_bin kodējumā parādās ķeburi (tie ir arī datu bāzes ierakstos, bet uz Windows kastes viss darbojas bez problēmām). Tātad: Kur varētu būt bēda? Vai ir jāpārkonvertē datu bāzes ieraksti kādā citā kodējumā? Vai varbūt problēma varētu būt PHP iestādījumos? (jāmaina php.ini) Vai varbūt kopējot ir nomainījušies kodējumi? (apšaubāma versija, vai ne?) Kāds cits iemesls? Un pats galvenais - kā to risināt? Paldies par Jūsu laiku!