ugrás a tartalomhoz

Archívum - Jan 2015

január 7

Irányváltás

Hidvégi Gábor · 2015. Jan. 7. (Sze), 13.17

A HTML alapú adattárolás és -megjelenítés számtalan gonddal küzd, ráadásul nagyon kevés olyan fejlesztő vagy döntéshozó van, aki komolyabban foglalkozna velük. Álljon itt egy lista a legsúlyosabbakról, s végül arról, hogyan lehetne a mostani spirálból kikeveredni.

fb borítókép szerkesztő program

Radon · 2015. Jan. 7. (Sze), 10.37
A weboldalamra szeretnék én is betenni olyan editort, amit képfeltöltés után tudsz használni, hogy méretre igazítsd a képedet. ilyen a facebookon a borítókép szerkesztő is. Tud valaki ilyen programot?

köszi
 ■

január 6

DateTime, strtotime érdkesség

Kubi · 2015. Jan. 6. (K), 15.05
Sziasztok!

Nem találtam a neten erre vonatkozóan infót, ezért írok ide, hátha valaki fel tud világosítani, hogy miért is így működik a dolog.

DateTime-ot használok idő validálásra (pontosabban az sf1.4 date validátora), viszont a DateTime és az strtotime is ha egy karakteres string van megadva, simán megeszi és visszaadja az aktuális dátumot. Két karakter esetén már hibát dob.

$date = "y";

var_dump(strtotime($date));
var_dump(new DateTime($date));
fenti kód kimenete

int(1420593950)
object(DateTime)#1 (3) {
  ["date"]=>
  string(19) "2015-01-06 13:25:50"
  ["timezone_type"]=>
  int(2)
  ["timezone"]=>
  string(1) "Y"
}
Ez alapján időzónának veszi az egy karakteres stringet, de én A..Z ig terjedő időzónákról nem tudok, dokumentációban sem látok erre utalást. Ti tudtok erről valamit? Mi kerülte el eddig a figyelmemet?
 ■

Node.js is Enterprise-Ready

MadBence · 2015. Jan. 6. (K), 01.10
A Node.js technológiailag már érett platform
 ■

január 5

Custom font probléma ékezetes karakterek esetén

Horváth Norbert · 2015. Jan. 5. (H), 21.53
Van egy problémám az alábbi oldalamon: tarsasjatekwebshop.hu
Az Open Sans nevű font-ot húztam be a google fontok közül amit a css-ben @-rule módszerrel használok. Az a probléma, hogy ha a felhasználó gépére nincs telepítve a font, akkor az őűŐŰ betűket hibásan jeleníti meg. Pl itt látható a dialog címsorában: http://webprog.biz/images/2015-01-05_204526.png
Az érdekes az, hogy ha a felhasználó gépén telepítve van, akkor jól jelennek meg ezek a betűk is. Amúgy az oldalon minden kódolás utf-8.
Van valaki aki esetleg tapasztalt már hasonlót vagy tudja a megoldást? Előre is köszönöm!
 ■

MVC outdated?

pythonozok · 2015. Jan. 5. (H), 21.26
Blogmarkként talán jobb lett volna, de nem találom, hogy hol olvastam: állítólag az MVC pattern már idejétmúlt, felejtős.
Ez valóban igaz lenne vagy csak véletlenül egy újító hangulatú fejlesztő blogjába botlottam tegnap?
Ha igaz, mi ajánlott helyette?
És itt most nem csak (sőt elsősorban nem) webes fejlesztésben gondolkodnék.
 ■

On PHP Version Requirements

Hidvégi Gábor · 2015. Jan. 5. (H), 19.02
Miért érdemes folyamatosan frissíteni a PHP-t
 ■

Pitfalls of Callback-Based APIs

Hidvégi Gábor · 2015. Jan. 5. (H), 18.50
A callbackek problémái, megoldási javaslatok
 ■

Elköltözött a Weblabor

Joó Ádám · 2015. Jan. 5. (H), 17.56

Az év vége a Weblabor körül lázas munkával telt: korábbi szolgáltatónk, a PHPHost befejezte működését, így rendszereinket a nekik új otthont adó szerverekre kellett költöztessük.

január 3

Pár elemes listák

szabo.b.gabor · 2015. Jan. 3. (Szo), 09.50
Sziasztok!

Problémám a következő. Vannak egy csomó ~30 elemű listánk, aminek az értékeit aztán tároljuk különböző rekordokban (ott nyilván integerként).

Néha exportálgatunk, ott nem árt ha olvashatóan szerepelnek a dolgok, és néha szeretjük, ha az exportot kiköpi az adatbáziskezelő.

Mi a legoptimálisabb megoldás?

I.
Minden listának külön tábla?

pro
-idegen kulcsok szépen működnek
-minden szép és jó

kontra
-nem overkill?
-a sok hülye tábla, amik között nem találjuk meg a tényleg használt táblákat.

II.
Csinálunk lista_csoport és lista_elem táblákat
#lista_csoport#
-idcsoport (pk)
-csoport (varchar)

#lista_elem#
-idelem (pk)
-idcsoport (fk)
-elem

És az idelem értékeket tároljuk ahol kell.

pro
-kevés tábla
-külső kulcsok részben működnek

kontra
-különböző csoportok pk-i keverednek, a kulcs nem hordoz az ember számára semmiféle értelmezhető információt (ez azért néha nem rossz). esetleg szorozzuk meg a csoport azonosítót százzal és ebben az intervallumban tároljuk a lista elemeit (ez ám a gány, de talán nem is olyan hülyeség)
-olyan kulcs is kerülhet adott helyre, aminek ott semmi értelme (egy totál másik csoporthoz tartozik) (mondjuk ha a csoport azonosító benne van az elem kulcsban, akkor akár lehet rajta egy könnyen megírható trigger)

III.
lista_elembe felveszünk még egy mezőt, ami az adott érték indexét tárolja, de ez még nagyobb butaság, mert vagy két mező lehetne idegen kulcs, vagy nem tudná kezelni az idegen kulcsokat az adatbázis (azért nem baj, hogy nem tudok berakni olyant ami nem létezik)


----------
Csak SQL segítségével lehet ezt normálisan kezelni, vagy van valami értelmes megoldás erre a problémára?
 ■