ansis
-
Posts
42 -
Joined
-
Last visited
Posts posted by ansis
-
-
Atradu un uztaisīju.
Diemžēl uz IE nedarbojas, bet uz pārējiem - viss notiek.
Rezultātu filtrēšana uz ekrāna klienta galā, bez pieprasījumiem no db.
Apskatīt var te:
www.psihoterapija.lv/?page_id=19
-
tur reali tiek katru reizi meklets ieksh DB .. tas kods buus Ljoti leens....
--> skaisti jau izskatas , bet noslodze DB nezeliiga (iedomajies ja mekleju vardu no 10 simboliem ) --> tas ir 10 pieprasijumi DB
+ sadalijumam pa lapam .. utt....
---
edit: a taa izmanto OnChange eventu ....
Paldies.
Pats skatījos lapas kodu, bet īsti nesapratu, kā tas uztaisīts.
Domāju, ka ir kaut kāda fiška, kādā veidā var 1) dabūt rezultātu no db un 2) ar javascriptu dinamiski attēlot tikai daļu - bet, acīmredzot, viss ir vienkāršāk (un sarežģītāk)...
-
Un kur tieshi ir probleema ? Tu tachu saproti, ka tavaa vietaa neviens nerakstiis ?
Paldies, kaut kā pašam tas nebija ienācis prātā... Bez tavas palīdzības, andrisp, nu nekādīgi to nebūtu sapratis.
Vēlreiz tencinu par viedajiem, un, galvenais, nenovērtējami palīdzošajiem vārdiem!
-
interesē uztaisīt sekojošu lietu: ar php no sql uz ekrāna dabūju tabulu, bet vēlētos papildus rezultātus atfiltrēt - refrešojot pēc katra simbola.
Piemērs:
http://www.nowtorrents.com/search/jazz
Labajā pusē ir lodziņš "Filter results". Ierakstot tajā iekšā kaut ko, piemēram "smooth" parādās tikai tās rindiņas, kurās ir šis 'smooth'.
-
...ar exec/system izpildi to mysqldump ....
Atvaino, nezinu, kā šo izdarīt?
-
Vai ir iespējams/kā ir iespējams dabūt db eksportu, izmantojot php/sql komandas?
Resp: phpMyAdmin nav pieejams, arī cita veida pieslēgšanās db.
BET - ir iespējams uzlādēt un izpildīt php skriptus.
Vai šādā veidā ar kaut kādu sql komandu var izeksportēt visu db failā/uz ekrāna?
-
Subjektā viss pateikts.
Ilgu laiku darbojos uz PC, tagad ieviesu jauno intel Mac.
Ir daži jautājumi, par kuriem gribētu konsultēties, kas ir Mac specifiski.
ir te kāds, kurš lieto OS X?
p.s. citādi visiem - priecīgu līgo!
-
Kāpēc tas vajadzīgs?
Negribu katru reizi f-jas iekšpusē rakstīt global pie mainīgajiem, kas man ir vajadzīgi VISĀS funkcijās, un kartu reizi, kad kaut kas pamainās, mainīt ierakstu pie KATRAS funkcijas.
Varbūt šo pašu var atrisināt ar koda rakstības stilu un risināt citādi - bet man radās šāda vajadzība.
-
Līdz OOP vēl neesmu ticis.
Pagaidām lietoju tikai include un funkcijas...
Ir tāda iespēja?
-
Droši vien elementārs jautājums:
Zinu, kā var no funkcijas iekšas atsaukties uz mainīgo, kurš definēts ārpusē.
Bet vai var otrādi?
Nodefinēt mainīgo un pateikt, ka šis ir pieejams visām funkcijām, visiem skriptiem, nerakstot katru reizi
global $a;
?
-
mysql_query("SET NAMES UTF8");
1 reizi pee conekta ar DB...
Zini, šis tiešām palīdzēja! - Ideāli!!! Paldies, Pelēci :)
(biju jau gandrīz zaudējis cerības un sāku plānot 3 tabulas un lpp charset, kurš mainās atk. no izvēlētās valodas... ;)))
-
Netieku pats galā ar 3 valodu saita encoding.
Tabula:
ID | txt_lv | txt_ru | txt_en
01 | Rīga | Рига | Riga
Kamēr lietoju phpMyAdmin, redzu latviskus, krieviskus tekstus, visu varu redzēt/rediģēt.
Kad mēģinu pieslēgties ar savu skriptu, tā lv/ru burtu vietā rādās ???????.
lpp hederī ir:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
Kā rāda phpMyAdmin,
txt_ru un txt_lv character set ir utf8
Esmu mēģinājis mainīt arī uz utf8_bin, utf8_general_ci, bet nepalīdz.
Serveris: php 4.4.1, mysql 4.1.12
$_SERVER[HTTP_ACCEPT_CHARSET] => windows-1257,utf-8;q=0.7,*;q=0.7
ja lv|ru tekstu esmu ierakstījis statiski - html-ā, tad tas rādās korekti.
Ko es daru nepareizi? Kā panākt, lai visas valodas rādās, kā nākas?
p.s. bubu sarūpēto satura rādītāju izpētīju, bet atbildi neatradu :((
-
Uztaisi takš EventLogu
vai ņem manējo...
Paldies par piedāvājumu, bet - klasēs vēl neesmu iebraucis - vienu reizi mēģināju, bet pagaidām izlēmu iztikt bez.
kādu laiku palietoju TunT, bet tagad viņi izdomājuši būt maksas.
Tad nu atkal atgriežos pie šī jautājuma.
Šobrīd kā risinājumu esmu iztēlojies:
Man katrā lapā ir include(header.php).
Headerī ielikšu f-ju, kura vienā tabulā pieraksta dažas $_SERVER mainīgā vērtības.
Pēc tam atliek tikai analīze.
-
Tu pārprati tā </li> nevajadzīgumu.
Nav tā, ka tad kad neliek to </li> tad drīkst sazin ko mest pa vidu. Tā nu gluži nav gan.
Vienkārši HTML parseri būtu pašam jāmāk noteikt, ka </li> tags jāliek pirms nākamā <li> tagad. Tā ka - citus tagus nevajag un nedrīkst likt kā UL childus.
bubu: - tas atceļ manu jautājumu tādējādi, ka => ja nelieto </li>, tad zem <ul> vairs nav tādas vietas kā manis minētā
., vai Tevis minētāstarp </li> un <li>
Citiem vārdiem sakot, katram </li> ir jāatrodas tieši pirms nākošā <li>. (ok, vai pirms </ul>).. pa vidu...Pārējiem:
Man tika uzdots jautājums "kur izraki, ka </li> nav obligāts". Norādīju sourci - manuāli, specifikāciju, linku.
Ir citas valodas, specifikācijas, manuāļi, kuros rakstīts kaut kas cits - visus nepārzinu.
Ir visādi XML un XHTML, par kuriem īsti neko nezinu - esmu dzirdējis tikai pa ausu galam.
Piekrītu, ka ir labais kodēšanas stils, bla bla bla, bet šis bija vienkāršs jautājums... :)
-
kur tu izraki ka tags nav jāaizver.. xhtml visi tagi ir jāaizver, gan jau tad html 4 ar vismaz rekomendē visus tagus aizvērt un nelikt browseriem minēt kur tev tagi beidzās.
Kā jau teicu: rtfm
http://www.w3.org/TR/html401/struct/lists.html
<!ELEMENT LI - O (%flow;)* -- list item --> <!ATTLIST LI %attrs; -- %coreattrs, %i18n, %events -- > Start tag: required, End tag: optional
-
...Kāpēc neviens vairs nelasa dokumentāciju?...
Paldies. Palasīju dokumentāciju.
Izrādās, ka var arī šādi:
<ul> <li>1 <ul> <li>1.1 <li>1.2 </ul> <li>2 </ul>
(beigu </li> nav obligāts, kas atceļ manu jautājumu par to, vai kaut kas var atrasties starp </li> un <li>)
RTFM
-
Sveiciens!
Man atkal ir šāds jautājums.
Kā rakstīt ir pareizi, ja listē grib iekļaut citu listi?
1. variants:
<ul> <li>1</li> <ul> <li>1.1</li> <li>1.2</li> </ul> </ul>
vai 2. variants:
<ul> <li>1</li> <li> //vai šis li ir vajadzīgs? <ul> <li>1.1</li> <li>1.2</li> </ul> </li> //vai šis li ir vajadzīgs? </ul>
Principā strādā abi. Esmu šur un tur redzējis lietojam arī abus.
Bet kā ir ar noteikumiem - vai drīkst kaut kas atrasties starp </li> un <li>
<ul><li>x</li> tas ir te... <li>x</li></ul>
Šis (vismaz man) rada lielas savietojamības problēmas pielāgojot CSS priekš IE un FF
-
... FROM vardi as v1, vardi as v2 ...
Viltiigi - vienu un to pasu tabulu apsaukt 2 dazaados vaardos! :))
Paldies, Bubu!
-
Sveicieni!
Man sekojoss jautaajums:
Ir 2 tabulas:
vardi
-------------
id_v | vards
-------------
01 | Janis
02 | Juris
03 | Peteris
saites
id_s | id_v_1 | id_v_2
------------------------
01 | 01 | 02
02 | 02 | 03
03 | 01 | 01
Kaads izskatiisies selects, lai dabuutu aaraa
saites:
01 | Janis | Juris
02 | Juris | Peteris
03 | Janis | Janis
Kameer ir viena saite, tikmeer es maaku. Kad ir saites uz 2 dazaadaam tabulaam (3 tabulu joins), arii var uzrakstiit. Bet, kad jaapraksta saite uz vienas tabulas 2 laukiem vienlaiciigi, taa aplauzos. :(
-
Vajadzība sekojoša:
Pierakstīt ciparus (teiksim, vērtējumus). Vēlāk ar tiem veikt darbības - summēt, vidējot, utt.
Bet - reizēm cipars nav, resp. vērtējuma var nebūt (N/A). Tas ir cits gadījums, nekā "vērtējums=0".
Jautājums - kā šo reģistrēt db?
Kādu lauka tipu izvēlēties?
Ja izvēlos teksta lauku, tad jāveic ifi un konversijas aprēķiniem.
Ja izvēlos num, tad nevaru pierakstīt vērtību "n/a".
Variants, kas pašam nāk prātā - kaut kādu skaitļa vērtību, piem "1000" uzskatīt par n/a, un pirms aritmētikas veikšanas pārbaudīt - JA (vērt=1000) TAD (vērt="n/a"). Bet tas šķiet diezgan kokaini.
Varbūt ir labāki ieteikumi?
-
OK, shii diskusija bija par funkcionalitaati, nevis dizainu.
Katraa gadiijumaa paldies visiem, kuri piedaliijaas/padaliijaas. Sho to jaunu atklaaju, bet jautaajumi arii ir palikushi.
Katraa gadiijumaa par kaartosanu ar <div>iem ir skaidrs - daudz lielaaka elastiiba, no vienas puses, un - var riktiigi nop*sties, meeginot dabuut kluciiti tajaa vietaa, kur tam jaabuut - pie tam, lai tas korekti straadaa dazaados browseros.
Piem - paliek jautaajums, kaa lai <div> pielipina saakotneejaa ekraana apakseejai malai?
Nu, ko? Teema sleegta?
-
Ar <table> man skiet daudz vieglaak uztaisiit taisiit dizainu, kursh izskatiitos taa, kaa gribu.
OK, esmu uztaisiijis versiju bez nevienas <tables>, viss dizains ir pasleepts ieksh css.
(taas bija mociibas diezgan...)
http://www.psih.lv/d/index.php?cat=1
FF neskrolleejas!!! (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7)
IE - skrolleejas.
-
-
<div style="width: 440px; height: 370px; overflow: auto;"></div> Un viss skrollējās uz nebēdu, gan FF, gan IE.
Viss (resp, viss dizains) tiešām skrollējas.
Bet teksts, kurš atrodas iekš diva, ja tas ir garāks?
<div style="width: 440px; height: 370px; overflow: auto;"> Te ierakstām GARU tekstu. ......................... ......................... </div>
Dzīvē paraugs ir te: http://www.psih.lv/index.php?cat=1
Wordpress un SET NAMES UTF8
in Iesācējiem
Posted · Edited by ansis
Lūdzu, palīdziet tikt galā - pats nevaru izburties.
Ir dots: vecs Wordpress blogs, kurā ir jau daudzi ieraksti. (Latviski, krieviski, angliski.)
Savulaik bija problēmas ar LV burtiem (ķeburi LV burtu vietā), kuras tika atrisinātas atbilstošā vietā ierakstot leģendāro SET NAMES UTF8.
Tas bija sen - kāpēc tādas problēmas radās - neatceros, bet risinājums bija derīgs, tāpēc arī tāds palika.
Tagad, katru reizi atjaunojot uz jaunu Wordpress versiju, atkal ar roku ir jāieraksta tas pats SET NAMES UTF8.
Izveidojot blakus jaunu, tīru blogu (ar oriģinālajiem uzstādījumiem - bez pievienotā "set names"), nav problēmu ar LV burtiem - viss rādās korekti - gan pašā WP, gan iekš phpMyAdmin.
Bet, atjauninot jaunu WP versiju manam vecajam blogam, bez tās UTF8 modifikācijas ir ķeburi.
OK, es varu pieņemt, ka esmu ievazājis to sērgu un turpināt katru reizi rakstīt klāt to vienu rindiņu, bet - varbūt ir kāds cits risinājums? Pārkodēt visu SQL tabulu, lai tā būtu pareizajā formātā? Kā lai to noskaidro?
Cik spēlējos ar pašu tabulu kodējumiem, tas neko nedeva. (tīrai WP instalācijai ir "Latin 1" - mēģināju nomainīt uz to, bet tas nedarbojas)
Paldies jau iepriekš!