tas_pats
-
Posts
52 -
Joined
-
Last visited
Posts posted by tas_pats
-
-
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.
-
Tas ir īsais datuma formāts. Visiem ir arī garais ar 4 gada cipariem.
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!
-
Man domāt, ka kaut kā tā
Iepriekšējais:
SELECT name FROM documents WHERE date <=xxx AND id<x ORDER BY date DESC,id DESC LIMIT 1
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.
-
Vienkāršām lapām es parasti neglabāju datubāzē dažādus tabuliņu kolonu nosaukumus un līdzīgas lietas. Izmantoju kaut ko līdzīgu kā hmnc norādīja pirmajā variantā, vienīgi es nelietoju to tādā stilā: title_lv, title_en, title_ru, tā vietā es zimantoju mainīgos (kaut gan parasti masīva elementus), ar vienādiem nosaukumiem katrai valodai (caption_count, caption_price, caption_color, button_ok, button_cancel). Katrai valodai ir atbilstošais fails, piemēram, language_lv.php, kur ir sadefinēti valodas masīva elementi un, kas tiek includots atbilstoši izvēlētai valodai. Ar šo pieeju nav nekādu problēmu pievienot jaunu valodu, jāiztulko tikai viens fails.
Vēl vienai mājas lapai izmantoju xml, pēc pieredzes saku, labāk nevajag.
Neesmu nopietni pētījis gettext paplašinājumu, bet liekās ka to arī var izmantot lokalizācijas jautājumu risināšanā. Pielabojiet ja kļūdos.
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.
-
exec() has been disabled for security reasons
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!
palidziba ar Scripta izveidi
in Iesācējiem
Posted · Edited by tas_pats
Ko tu mēģināji paveikt un kas tieši tev nesanāca ?