des

<meta http-equiv="refresh" content="; url=Zinja.php">

Vaac aaraa to rindinju! Taa tieshaam taisa muuzhiigo refreshu :)

Visu insertoshanu taisi pashaa augshaa (pirms jebkas tiek izvadiits uz paarluukprogrammaa).

if (sizeof($_POST)>0) {
   insertoshana datubaazee.
   header('location: Zinja.php');
}

nu tad saac ar:

<?php

  echo "Hello World!";

?>

:)

Pierakstiiju to hedu . Lapa aizgaaja muuzhiigaa refreshaa! un sameta n-tos komentus vienaadus

pirms refreshoshanas (headera izsauksnanas) uztaisi paarbaudi, vai ir notikusi postoshana.

if (sizeof($_POST)>0) {

   header("location: .....");

}

Tieši to pašu es gribētu teikt par tabulu veidojošo klasi - lai paredzētu visus tabulu veidus, kādus vien var ievajadzēties, tev nāksies 20 reizes izgudrot jaunu divriteni, pie tam tu tikai lieki sarežģīsi savu kodu. OOP ir izmantojams vietās, kur tas dzīvi atvieglo, nevis rada liekas problēmas.

 

Tam visam ir viens iemesls - tu nevari paredzēt un iekļaut visus formas atribūtus savā OOP kodā. Kaut vai viens piemērs - uztaisi man ar savu OOP kodu read-only text input lauku.

Nepiekritiishu. Esmu uzrakstiijis sev tabulu gjenereejoshu klasi, ar kuru var sagjenereet jebkaadu tabulu.

Par atribuutiem. Prieksh tam man html objektiem ir parametrs $attr, kuraa tad kaa masiivu mieriigi sabaazhu jebkurus taga parametrus, kuri ievajagaas.

Saapes saakas tieshi tajaa mirklii, kad pietiekoshi daudz un dinamiskus colspanus un rowspanus jaataisa bez sakariigas OOP pieejas.

Taa kaa nav nemaz taa ideja tik slikta, ja visu pietiekoshi flexibli izplaano.

Pilniibaa esmu apmierinaats :)

brīdī, kad būsi daudz maz apguvis OOP un tā iespējas, sapratīsi, ka PHP gadījumā pilnīgs OOP ir bezjēdzīgs - notiek lieka lietu sarežģīšana vismaz PHP4 gadījumā pilnīgi noteikti.

Heh... nu var jau katram projektam rakstiit savu klasi $application, kuraa tad sabaazst visas "briivaas" fjas un "briivos" mainiigos. Viens pluss tam ir - nav jaadomaa tik daudz, ka tik neaizmirst kaadaa fjaa nodefineet kaadu globaalo mainiigo. Neesmu gan nekad taa dariijis :) Tas veel vareetu atmaksaaties, ja taisa lielu intraneta aplikaaciju priesh nedaudziem lietotaajiem. Bet, ja jaataisa intensiivas lietoshanas web-aplikaaciju, tad gan naakas atgriezties pie vecajaam labajaam f-jaam un centiigi piedomaat, pie katras i/o operaacijas.

un pirms tikai jaaparliecinaas, ka defaultajaa charsetu direktorija ir atrodams fails cp1257.conf....

tb, mysql/share/charsets/cp1257.conf

Nepietiek, ja tur ir taads fails! Veel tam ir jaabuut iistajam cp1257.conf failam...

Tas, kas naak liidzi mysql installaacijai (vismaz 4.0.16), NEordero pareizi ar lv burtiem.... Ir jaanokachaa netaa pareizais fails...

piemeeram:

http://www.datorklubs.lv/~martins/mar/cp1257.conf

Gandriiz buutu jau noshaavies, ja to nebuutu atklaajis :ph34r:

Neironu tīklu pats taisīju (diezgan primitīvu, speciāli šim gadījumam). Vienkāršs vienslāņa perceptons un, laikam arī biju eksperimentējis ar kohonena pašapmācošo tīklu, bet ar to mazāki panākumi, jo tie simboli šausmīgi izkropļoti bija pēc rūtiņu noņemšanas.

Ar vienslaanja perceptronu toch vareetu buut par maz, jo vienslaanjnieki ir baigi vaajie. Vajag daudzslaanju. Bet tie savukaart bremzee :/

Ar include var includod kaut vai:

include("manu/kakji/sauc.jaanis");

:)

Es laiku pa laikam arii shajaa forumaa, izmantojot search, atrodu prieksh sevis ko noderiigu.

Taadi cilveeki, kas uzdos jautaajumu, kas 2 tematus ieprieksh jau apskatiits, vienmeer taa vai taa laiku pa laikam uzradiisies.

Pie tam ar laameem arii vajag runaaties iecietiigi, jo biezhi cilveekiem vienkaarshi tieshaam googljoshanas skills nav uzkachaats.

Cilveeki sheit naak, lai uzdotu jautaajumus, kurus nezin, nemaak atrast vai arii ir par slinku, lai atrastu citur - bet iemels jau ir vinju pashu probleema. Ja reiz cilveeks sheit kaut ko ieposto, lai arii cik stulbi un lameriski kaadam tas neliktos, tad tas noziimee, ka cilveeks grib atrast probleemas atrisinaajumu.

Katram, kas sevi uzskata par nelaami tad nu ir tiesiibas izveeleeties, vai paliidzeet shim cilveekam.

Njaa - tas ir forums, kuraa vinjsh spamojas principaa pats ar sevi :DD

Post formas piemeers wml:

  <wml>
  <card id="search" title="Meklēšana"
   <do type="accept" label="Meklēt">
    <go href="search.php?how=dosearch" method="post">
     <postfield name="Query" value="$query"/>
  </go>
   </do>
  <p>
    Frāze: <input title="Query" name="query" size="9"/><br/>
  </p>
  </card>
  </wml>

peec tam php tiek klaat caur

$GLOBALS['Query']

sen neesmu ar wml neko dariijis, bet man taadaa veidaa straadaaja...

Ar php var gjenereet arii WML.

Taalaakais interfeiss starp php un mysql jau ir tieshi taads pats, kaa vienmeer.

Nu vajag tachu uztaisiit taa, lai nesuuta ar epastu priekshaa :)

Piem, var suutiit tikai ar simboliem "<>" priekshaa :) taa iiszinjai paliek 158 simboli :P

te ruina gaaja, ka oop neesot iipashi aatrs.

vai varat mineet kaadus piemeerus?

es personiigi esmu noveerojis preteejo.

gribu redzēt tavus maņu orgānus, ka tu to novēroji . Ir kāds reāls testu piemērs ar benchmarkiem?

Vinjsh droshi vien domaaja, ka taisiit projektu, izmantojot OOP ir aatraak.

Protams, ja ir klase, kurai ir viens parametrs, kuru echo, tad starpiiba iipasha nebuus, tomeer kaa jau mineeju, tad, piem, ja katru html tagu uztaisam par objektu, tad gan tas viss darbojas ~10x leenaak. tiesa, par to mees ieguustam daudz reiz eertaaku kodeeshanu :) Lai kaads pameegjina bez oop (pie tam mikseejot pa tiesho outputu ar pashu algoritmu) uztaisiit html tabulu, kurai briivi var teiksim ar rectangle mainiit jebkurus td atribuutus(padodtot x1,y1,x2,y2,attribuutu_masiivs), pie tam katra shuuna atkal var satureet citu patvaljiigu tabulu, formu/whatever.

A tas, ka var ar PrintScreen nofotografēt ekrānu Tevi neuztrauc? Pret to IMHO nepalīdzēs nekas. :-)

:D :D :D :D :D

Gan jau, ka, izmantojot caurumaino IE ar kaadu hvz kaadu activeX vai whatever var arii pacensties un PrintsScreen nodiseiblot :rolleyes: :rolleyes: :rolleyes:

nu ir javascripts, kas vispaar diseiblo labo peles klikshji (Go pac 2 google, tur toch jaabuut, no galvas nezinu). bet taapat cherez view source var paskatiities celju uz bildi un atveert bildi pa tiesho browserii... tad arii papildus jaalieto kaut kaads Html Guardians vai kaut kas tamliidziigs...

nepiekritīšu Tev, des. KĀRTOT PIRMS GROUP BY nebūs pareizi, jo imho neviena DB nesaka, kādā secībā iedos sagrupētos rezultātus. manuprāt kārtošana jāveic pēc GROUP BY.

***

doma ir, ka ir viens selects, kuraa vispirms sakaartojam datus vajadziigaa kaartiibaa, peec tam jau no shii selecta rezultaatiem veicam selectu, kuram tad ir tas group by.

***

shiis teemas jautaajums bija, kaa ietekmeet pashu group by, ja neizmanto nevienu agregaatfunkciju :)

arii

"select n,t,max(i) as mi from tbl

group by n

order by mi"

nekaadi nespeej ietekmeet kolonnas t veertiibu - group by vienkaarshi panjem pashu peedeejo (kura ir peedeejaa, to zina tikai jamais pats :) ).

arii tas, ka katraa grupaa veel ieselekteejam max(i), min(i), whatever(i) nekaadi nespeej ietekmeet t veertiibu :) un order by peec group by vairs neko nespeej ietekmeet :)

tikko paarbaudiiju, ka Oracle, piemeeram, uzreiz pie

"select n,t from tbl group by n "

izmet, ka t "is not a group by expression".

taa luuk.

taa kaa nav, ko briiniities, ka SQL specificaacijai neatbilstoshi queriji, kurus mysql tomeer palaizh cauri, izdod gljukainus rezultaatus :)

Principaa jau group by savu darbinju izdara pirms order by.

Respektiivi tabula kaut kaa ir jaasakaarto ar citu kveriju jau pirms peedeejaa group by izsaukshanas. Vajadziigs subkverijs. (select * from select...)

select `name`, `text`
from `table`
group by `name`
order by max(`id`) desc

shis gan met aaraaa

"invalid use of group function"

(vismaz uz versijas 4.0.16)

Ugu, mysql tieshaam visu biezhi nevar tik pat skaisti sagruust vienaa selectaa kaa piemeeram kaada oraclee :) visaadi starprezultaati jaapiefixee ieksh php un jaadarbojas ar vairaakiem selectiem :) mysql baigi pietruukst storeetaas funkcijas un proceduuras :)

Redzi, peec relaacijas definiicijas ir taa, ka ieraksti pashi par sevi tabulaa nekaa nav sakaartoti. Tikai ar visaadiem order by Tu vari panaakt sev veelamo rezultaatu. Un group by tieshaam ir izmantojams tikai pie visaadaam agregaatfunkcijaam, tjipa sum, avg, count....

***

Bet, lai panaaktu to, ko Tu gribi, man domaat, bez subselecta/viewa neiztikt (ar kuriem MySQL pagaidaam veel ir taa pashvakaak)

Tjipa tad vareetu pievienot tabulai veel id lauku, kas ir autoincrements. Vispirms noselekteet tabulu, sakaartotu peec id preteejaa virzienaa un tad no taas taisiit Tavu jociigo group by selectu. Aptuveni taa.

Lai nebuutu jaakakaajas ar preg_matchiem (jo no ~60k sarezhgjiita html coda preg_matchi nezkaapeec vienmeer panjem kaut ko par daudz vai nekorekti), uzrakstiiju shitaadu sakainu fju vienreiz. Liidz shim ir ljoti labi straadaajusi, lai savaaktu kaut kaadus vajadziigos datus no kaut kaadaam lapaam.

function get_text_between($str1,$str2,$in) {


       $a1=strpos($in,$str1,0);
       $a2=-1;
       $c=0;
       while ($a1>$a2) {
               $a2=strpos($in,$str2,$c);
               $c++;
       }
       $l1=strlen($str1);
       $l2=strlen($str2);
       $l=strlen($in);
       $r=substr($in,$a1+$l1,$a2-$a1-$l1);
       
       if ($a1==0) return false;


       return $r;



}

un pielietoshana:

<?php

$text='btfgsdajgsdjghsdfgghdfsSuds1teirtaskasstarpsuudiemSuds2';

$res=get_text_between('Suds1','Suds2',$text);

echo $res;


?>

rezultaats:

teirtaskasstarpsuudiem

jaa, man arii domaat, ka efektiivaak tomeer izmantot php iebuuveetaas fjas, tjipa,

in_array($vards,$lamuvardi), jo buuveet AVL ieksh php man reaali neliekas praata darbs - jo tajaa vaardi buus jaaielasa pie katra lapas loada, kas man domaat nespeetu nosegt ieguvums uz nolasiishanu no koka. php masiiviem ir taada laba iipashiiba, ka tie un tiem piesaistiitaas f-jas pietiekoshi labi un aatrdarbiigi implementee lielaako dalju nepiecieshamo datu struktuuru.

***

patiesiibaa jau AVL un citas perversijas datorikjiem maaca tamdeelj, lai vinjiem iegroziitu praatus aarpus statisko struktuuru progaam, un lai jamie nepiecieshamiibas gadiijumaa tieshaam maaceetu uztaisiit patvaljiigas, sarezhgjiitas datu struktuuras.

Nēnu protams, katrs raksta pa savam, bet mans uzskats tomēr paliek tāds, ka programmai ir jaabuut taadai:

1. Saņem ievaddatus

2. Sagatavo izvaddatus

3. Izvada izvaddatus

 

Un man liekas, ka sagatavojot izvaddatus saprotamāk tas viss notiek, ja tu to visu "kluci" iegāz vienā mainīgajā un tad tikai izvadi.

Shim es tieshaam pilniibaa piekriitu. Protams, ciesh aatrdarbiiba. Tachu viennoziimiigi ir efektiivi prieksh kaut kaadu uznjeemumu maajas lapaam/citiem projektiem, kuriemm ir kaadi 2000-10000 loadi dienaa, jo mudjiishanaas par katru milisekundi un optimizaacija biezhi panjem paaraak daudz laika. Pie tam sakariigi struktureetu ievaddatu apstraades kodu, kas nejaucas uzreiz paraleeli ar izvadi, ir daudz vieglaak saprast un modificeet, kaa arii taadaa veidaa ir relatiivi mazaak kljuudu.

Jaa, es arii biju baigi laimiigais, kad pirmo reizi uztaisiiju AVL ar visaam taam virsotnju rotaacijaam un viss normaali rulleeja :)