Qued

Kāpēc internetā tiek ieteikts xhtml dokumentos izvairīties no <b> un <i> pielietošanas?

Atradu vienu objektu, kuru noslēpjot skrollbārs pazūd. Tas ir ul saraksts (meņucim), kas ir pozicionēts absolūti. wtf?

Venom

Kur tu ņem tādus parametrus? CSS2 manuālī nemaz nav overflow-x.

Fig viņu zin, kas ar to margin vai padding; diemžēl nevaru atrast nevienu objektu, kurš varētu izraisīt problēmu. Ja salieku visam borderus, pāri dizaina labajai malai nekas neiet, tomēr kāda 5-6pix brīva vertikāla josla labajā pusē tiek uzzīmēta (to redz paskrollējot) :(

Venom

update:

Paprovēju uz sava reālā projekta.

Ar overflow: auto nez kādēļ parādījās apakšā horizontāls scrollbar.

Ar overflow: hidden pagaidām viss izskatās ok.

Venom

kā rāmi bodijam. Ko tad, ja bodijs nav 100% platumā un 100% augstumā? Vai tad var kaut kādus baigos marginus sānos uzlikt?

Javaskripts gan rullē nemērā :) Man gan nav skaidrs, kā javaskriptam pateiksi, cik kontents garš sanācis.

Venom

position: absolute - bet tas tak ir ārā no flow'a, vai tad tādam var dabūt rāmi apkārt visām 3 kolonnām?

Kavacky

Ok, piedāvā, lūdzu, man citu variantu, kā uztaisīt kolonnas.

Kavacky

nu tad jājautā, kas tev tas par īpašu firefoxu. Paprovē šitādu kodu:

<style type="text/css">
#container {
 border: 1px solid blue;
 margin-left: auto;
 margin-right: auto;
 width: 400px;
}
#col1 {
 width: 100px;
 float: left;
 background-color: #AAA;
}
#col2 {
 width: 200px;
 float: left;
 background-color: #CCC;
}
#col3 {
 width: 100px;
 float: left;
 background-color: #DDD;
}
</style>
<div id="container">
<div id="col1">bla bla bla</div>
<div id="col2">bla bla bla bla bla bla bla bla bla bla bla bla </div>
<div id="col3">bla bla bla</div>
</div>

Venom

Tavs variants atrisina problēmu. Lielais paldies.

Patiesībā pietiek, ja #container stilam pieliek klāt overflow: auto. Kam noder parametrs _height: 1%? Nebiju nemaz sastapies ar tādu parametru "_height".

Vobšem, ideja tāda: ir kopējais divs, kurā iekša ir sub-divi - kolonnas. Apmēram šitā:

<div id="container">
 <div id="col1"></div>
 <div id="col2"></div>
 <div id="col3"></div>
</div>

Pieņemsim, ka div'am "container" ir rāmītis (border) - ķipa, kopskatā ir trīs kolonnas un tām apkārt ir rāmītis. Rāmītis pastiepjas tik garš, cik gara ir garākā no kolonnām. Problēma: uz IE un Operas viss ir ok, bet uz Firefoxa - nekā. Div's "container" redzams kā maza, šaura strīpiņa pašā augšā - it kā būtu tukšs, attiecīgi rāmīša apkārt visam saturam nav. Wtf?

Jau iepriekš pateicos.

Delfins

> davai iegaumē 100 tabulas ar vidēji 20 kolonnaam - katru pozīciju un jēgu

Da par ko ir runa? Ja datu bāzi nav taisījis pilnīgs dibencaurums, tad tabulu un kolonnu nosaukumiem vajadzētu būt informatīviem. Nevaru gan iedomāties, kādam risinājumam varētu būt vajadzīgs 100 tabulas ar vidēji 20 kolonnām... Kas attiecas uz kolonnu numuriem, tie ir kārtas numuri pieprasījuma rezultātā, vai ne? Kas notiek, ja es select'ā piemetu sākumā vēl vienu kolonnu klāt?

Delfiins

imo, ja tu meegjinaasi palaisti pieprasiijumu

>select max(revision_time), price_std, count(*)

>from items_configurations

>group by itemid

sanjemsi pazinjojumu, ka price_std jaabuut iekljautam grupeeshanas kriteerijos

Delfiins

> pēdējo vērtību no value lauka

tavā gadījumā tiek dabūta maksimālā. Ja nu pēdējā nav maksimālā?

> vajag grupēt pēc fk1 un saskaitīt cik ierakstu katram fk1

taa jau nav probleema

>un dabūt pēdējo vērtību no value lauka

vot tā gan ir problēma. Ar viewiem varbūt kaut ko var saveidot, a tā vienkārši - diez vai.

>un atverot 2 baazes vienlaiciigi tikai nevajadziigi tiks nnoslogota op atminja

Taisnība. Tikai - cik tas ir nozīmīgi? Gaišākas nākotnes vārdā, domāju, upuris ir paciešams.

Zaļais vilks

A kas traucē turēt vienlaicīgi atvērtas divas db un prasīt te no vienas, te otras?

hnmc

te kaut kas ieminējās, ka draugiem.lv neesot rdbvs. Būtu jauki, ja cilvēks padalītos, kas tad šiem ir.

Toms

Man šķiet, ka nav būtiskas atšķirības ātrumā atkarībā no tabulu sadalīšanas vienā vai divās db uz viena pc. Bet tas ir tikai "šķiet", praksē neesmu pārbaudījis.

Toms

kāda p. pēc dalīt tabulas divās datu bāzēs? :) Kādēļ tas būtu forši no kodēšanas viedokļa?

hnmc

>visi 10k uzreiz nelūrēs pastakasti. sliktākajā gadijumā 5k lūrēs, citi darīs, ko citu (ja vien projekts nav tēmēts uz šo vēstuļu joku)

Paskaties uz draugiem.lv dienas vidū. Cik zinu, ļoti liela daļa no tiem ļautiņiem izmanto draugiem.lv iekšējo meilu kā čatu (lai arī diez vai kāds uz to tēmēja). Tā ka nevar paļauties uz to, ka "visi 10k uzreiz nelūrēs" - dzīvē ar tādu pieeju var ieberzties :) Nu ok, katram projektam ir savi apstākļi un noteikumi, dažreiz var gadīties, ka noslodze būs ierobežota. Tomēr, ja noslodze var būt dinamiska (neierobežota), labāk meklēt elastīgāku risinājumu.

Jā, db arī atrodas uz fs, tomēr, kamēr fs pēc idejas ir plika fs ar minimālu kešošanu, dbvs tomēr uztura papildus mehānismus ātrdarbības uzlabošanai lielas datu plūsmas gadījumiem.

Nu šur tur jau to pāriešan jaunā rindā pielieto gan. Piemēram, strādājot ar plaintext materiāliem - meiliem vai teksta failiem. HTML/XHTML izvadē tiešām newline parasti nav vitāli nepieciešams.

hmnc

man ir aizdomas, ka tev varētu būt taisnība. Uz nekrutas kastes ar vienkāršāku dbvs datu atlasīšana no 1M ierakstu tabulas varētu būt lēnāka nekā no failu sistēmas. Cita lieta, ka sistēmās parasti lietotāju dati tiek sasaistīti ar citām db lietām, tāpēc jau izgudroja dbvs.

Nezinu tikai, vai pie lielas servera noslodzes failu sistēma spētu tikt galā ar noslodzi; datu bāzes gadījumā maksimāli daudz biežāk pieprasīto datu tiek ielasīti operatīvajā atmiņa, bet failu sistēmas gadījumā pie katra pieprasījuma tiek grabināts hdd.

Toms

būtu baigi feini, ja tu tiešām pieķertos klāt un tā kārtīgi palasītu kādu grāmatu par relāciju datu bāzēm. Ja jau esi pielaists pie tik megaliela projekta, būtu jauki, ja nemākulības dēļ tas nenogrimtu. Labu veiksmi, un atcerieties seno teicienu - mācīties, mācīties un vēlreiz - mācīties. :)

Nu tad strādā pa dārgo :)

Man šķiet, ka, ja select'a nosaukums ir vienkāršs, tad arī pie multiple select aiziet tikai viena vērtība. Nosaukumu vajag tādu:

... name="selectbox[]" ...

un tad

foreach ($_POST['selectbox'] as $key=>$value) {
 mysql_query("insert bla bla bla values($value)");
}

rnc

neglabā bilžu indeksu failā, liec jamo sesijas mainīgajā. Vai arī, lietotājam atverot galeriju, uzģenerē viņam atsevišķu teksta failu ar unikālu nosaukumu un tālāk tikai padod šī faila vārdu - vis atava bilžu infa glabāsies katram lietotājam savā teksta failā.

Es laikam esmu dumjš, bet nevaru to kanālu atrast. Man ir mirc, a pie kāda servera lai slēdzos? kaut kādos ārzemju tipa ircnet serveros php.lv ir tukšs...

... kādreiz rakstīju iekš Context, tomēr tur nav koda priekšāteikšanas. Šobrīd darbojos ar ZDE (Zend). Skatījos arī Komodo, tur bija forši, ka varēja goda blokus paslēpt, tomēr Zendam debugošana ir vislabākā - Komodo debugošanu tā arī nezidevās piedabūt pie strādāšanas. ZDE mīnusi - aizņem daudz atmiņas un reizēm uzbremzē - sevišķi, ja kodā ir kāda sintakses kļūda un šis cenšas pasvītrot kļūdainās vietas.