Archívum - Május 2014 - Fórum téma
május 17
CSS3 animation több transform különböző időben
Van egy négyzet, amely úgy animálódik, hogy egyszerre meg is nő és forog is. Azt szeretném, hogy a két animáció szétváljon időben: először csak megnőjön (scale), majd elforduljon (rotate).Hogyan kell? Előre is köszi.
■
<!doctype html>
<html lang="hu">
<head>
<meta charset="utf-8">
<meta name="description" content="">
<meta name="keywords" content="">
<style>
.box1{
width:200px;
height:200px;
background:rgba(255,0,0,0.5);
position:absolute;
top:100px;
left:50%;
margin-left:-100px;
}
.box2{
width:200px;
height:200px;
background:rgba(0,0,255,0.5);
position:absolute;
top:100px;
left:90%;
margin-left:-100px;
}
@-webkit-keyframes movingbox{
from{-webkit-transform: scale(1,1); -webkit-transform: rotate(0deg);}
to{-webkit-transform: scale(1.6,1.6); -webkit-transform: rotate(360deg);}
}
.box2{
-webkit-animation:movingbox 5s infinite;
}
</style>
<title>CSS3 Animáció</title>
</head>
<body>
<div class="box1"></div>
<div class="box2"></div>
</body>
</html>
május 14
Validációs tervezési hibák
Szép napot!
Kíváncsi vagyok, hogy mit gondoltok a php validációról. Jó, ténylegesen nincs ilyesmi, de én nagyon furcsának találtam az alapvető hozzáállást a validáláshoz az összes kódban, amit eddig láttam. Gyakorlatilag már a kiindulásnál elbuknak, mert eleve rossz stratégiát választanak.
Alapból valahogy így szokás nekifutni php-ben a validálásnak:Symfony dokumentációból másolt kód - Form-Validation
Ez még a szerencsésebb eset. A szerencsétlenebb az, amikor külön controller-ben van a validáció és külön view-ban az űrlap létrehozása, és lapozgatni kell egyikről a másikra, hogy lássuk mi micsoda.
Miért rossz ez (legalábbis szerintem)?
Ha security-ről van szó általában mindenki a whitelist-es megoldásokat biztonságosabbnak tartja, mint a blacklist-eseket, mert könnyű kifelejteni, embereket, akiknek tiltani akarjuk az alkalmazás használatát.
Kíváncsi vagyok, hogy mit gondoltok a php validációról. Jó, ténylegesen nincs ilyesmi, de én nagyon furcsának találtam az alapvető hozzáállást a validáláshoz az összes kódban, amit eddig láttam. Gyakorlatilag már a kiindulásnál elbuknak, mert eleve rossz stratégiát választanak.
Alapból valahogy így szokás nekifutni php-ben a validálásnak:
// lib/form/ContactForm.class.php
class ContactForm extends sfForm
{
protected static $subjects = array('Subject A', 'Subject B', 'Subject C');
public function configure()
{
$this->setWidgets(array(
'name' => new sfWidgetFormInput(),
'email' => new sfWidgetFormInput(),
'subject' => new sfWidgetFormSelect(array('choices' => self::$subjects)),
'message' => new sfWidgetFormTextarea(),
));
$this->widgetSchema->setNameFormat('contact[%s]');
$this->setValidators(array(
'name' => new sfValidatorString(array('required' => false)),
'email' => new sfValidatorEmail(),
'subject' => new sfValidatorChoice(array('choices' => array_keys(self::$subjects))),
'message' => new sfValidatorString(array('min_length' => 4)),
));
}
}
Ez még a szerencsésebb eset. A szerencsétlenebb az, amikor külön controller-ben van a validáció és külön view-ban az űrlap létrehozása, és lapozgatni kell egyikről a másikra, hogy lássuk mi micsoda.
Miért rossz ez (legalábbis szerintem)?
Ha security-ről van szó általában mindenki a whitelist-es megoldásokat biztonságosabbnak tartja, mint a blacklist-eseket, mert könnyű kifelejteni, embereket, akiknek tiltani akarjuk az alkalmazás használatát.
május 12
MEGOLDVA Karakterkódolás hiba POST után Firefoxban
Sziasztok,
Tudom, lerágott csont a karakterkódolós szerencsétlenkedés, de egyszerűen nem jutok előrébb ezzel a problémával.
Egy már majdnem kész oldalon van egy pici bug:
Post után a karakterkódolás a Firefoxban visszaáll ISO-8859-2-re, így minden ékezet rosszul jelenik meg.
Következő oldalbetöltéskor már ismét rendben van az utf-8.
A head:Chrome, Opera, IE böngészőkben semmi gond nincs, Firefoxban post után rossz.
Van ötletetek, esetleg tapasztalat, hogy mitől fordulhat ez elő?
Köszönöm előre is.
Szerk: Azóta kipróbáltam ezt, de ez sem működik:
<meta charset="utf-8">
■ Tudom, lerágott csont a karakterkódolós szerencsétlenkedés, de egyszerűen nem jutok előrébb ezzel a problémával.
Egy már majdnem kész oldalon van egy pici bug:
Post után a karakterkódolás a Firefoxban visszaáll ISO-8859-2-re, így minden ékezet rosszul jelenik meg.
Következő oldalbetöltéskor már ismét rendben van az utf-8.
A head:
<!DOCTYPE html>
<!--[if lt IE 7]> <html class="no-js lt-ie9 lt-ie8 lt-ie7" lang="hu" xmlns:fb="http://ogp.me/ns/fb#" xmlns:fb="http://www.facebook.com/2008/fbml" xmlns:og="http://opengraphprotocol.org/schema/" xmlns:fb='http://developers.facebook.com/schema/'> <![endif]-->
<!--[if IE 7]> <html class="no-js lt-ie9 lt-ie8" lang="hu" xmlns:fb="http://ogp.me/ns/fb#" xmlns:fb="http://www.facebook.com/2008/fbml" xmlns:og="http://opengraphprotocol.org/schema/" xmlns:fb='http://developers.facebook.com/schema/'> <![endif]-->
<!--[if IE 8]> <html class="no-js lt-ie9" lang="hu" xmlns:fb="http://ogp.me/ns/fb#" xmlns:fb="http://www.facebook.com/2008/fbml" xmlns:og="http://opengraphprotocol.org/schema/" xmlns:fb='http://developers.facebook.com/schema/'> <![endif]-->
<!--[if gt IE 8]><!-->
<html class="no-js" lang="hu" xmlns:fb="http://ogp.me/ns/fb#" xmlns:fb="http://www.facebook.com/2008/fbml" xmlns:og="http://opengraphprotocol.org/schema/" xmlns:fb='http://developers.facebook.com/schema/'> <!--<![endif]-->
<head>
<base href="/" />
<meta http-equiv="content-type" content="text/html; charset=UTF-8" />
<meta http-equiv="content-language" content="hu" />
Van ötletetek, esetleg tapasztalat, hogy mitől fordulhat ez elő?
Köszönöm előre is.
Szerk: Azóta kipróbáltam ezt, de ez sem működik:
<meta charset="utf-8">
JQ - Each - táblázat kiirasa - BUG ?
Egy tömb tartalmát iratnám ki.
Egy kétoszlopos táblázat lenne, bal oszlopban a kulcsok jobban az értékek.
Az each indulása előtt kiirom a table tagot.
Majd a ciklusban a tr és td tagot,
bele az adatokat majd lezarom a td tr tagokat,
és a ciklus után kiirom a /table vege tagot.
/Ahogy azt php-ben szoktam csinálni foreach esetén./
IGENÁM, DE A JQ AZ ELEJÉN AMIKOR KIIROM A TABLE TAGOT
magától kiegészíti A LEZÁRÓ /TABLE taggal.
Pedig azt majd én zárnám le a ciklus után.
Ettől ilyen lesz a táblázat.:
<table></table>
<tr><td></td></tr>
És ráadásul a ciklus után megirt /table -t meg nem irja ki.
Mi az okosság ilyenkor ?
■ Egy kétoszlopos táblázat lenne, bal oszlopban a kulcsok jobban az értékek.
Az each indulása előtt kiirom a table tagot.
Majd a ciklusban a tr és td tagot,
bele az adatokat majd lezarom a td tr tagokat,
és a ciklus után kiirom a /table vege tagot.
/Ahogy azt php-ben szoktam csinálni foreach esetén./
IGENÁM, DE A JQ AZ ELEJÉN AMIKOR KIIROM A TABLE TAGOT
magától kiegészíti A LEZÁRÓ /TABLE taggal.
Pedig azt majd én zárnám le a ciklus után.
Ettől ilyen lesz a táblázat.:
<table></table>
<tr><td></td></tr>
És ráadásul a ciklus után megirt /table -t meg nem irja ki.
Mi az okosság ilyenkor ?
május 11
MYSQL
Sziasztok!
Hogyan tudok olyan lekérdezést készíteni egy elég nagy adatbázisból, hogy pl. 2000 recordból 500-at szeretnék kiválogatni (Egységes léptékben ... ha lehet) úgy hogy az első és az utolsó recordot is tartalmazza a lekérdezés.
Előre is köszönöm, ha valaki tudja a választ.
■ Hogyan tudok olyan lekérdezést készíteni egy elég nagy adatbázisból, hogy pl. 2000 recordból 500-at szeretnék kiválogatni (Egységes léptékben ... ha lehet) úgy hogy az első és az utolsó recordot is tartalmazza a lekérdezés.
Előre is köszönöm, ha valaki tudja a választ.
PHP - phar archive
Ha jól nézem a PHAR kb 1.5x lassabb, mint a normál PHP, viszont sok előnye van ezzel szemben:
- egyszerűbb másolni, telepíteni
- még véletlenül sem keverednek az adatok, az alkalmazás kódjával, így könnyebb róluk backup-ot készíteni, ami szintén lehet phar formátumban
- van lehetőség titkosításra és digitális aláírásra, elvileg talán még a sérült fájlokat is kiszűri, bár nem tudom, hogy checksum-ot mennyire néz automatikusan
Érdekelne, hogy mi a tapasztalatotok vele, illetve a vélemények is érdekelnek. (Csak most kezdtem el nézni, hogy miket tud.)
■ - egyszerűbb másolni, telepíteni
- még véletlenül sem keverednek az adatok, az alkalmazás kódjával, így könnyebb róluk backup-ot készíteni, ami szintén lehet phar formátumban
- van lehetőség titkosításra és digitális aláírásra, elvileg talán még a sérült fájlokat is kiszűri, bár nem tudom, hogy checksum-ot mennyire néz automatikusan
Érdekelne, hogy mi a tapasztalatotok vele, illetve a vélemények is érdekelnek. (Csak most kezdtem el nézni, hogy miket tud.)
május 8
Git, phpunit, Windows
Sziasztok!
Olvastam itt egy jó a cikket a gitről, ehhez kellene segítség. Gitem meg van és van phpunit is. Létrehoztam a phpunit futtatásához egy scriptet, a következőt használtam fel: Git és phpunit. Ebben leírja, hogy windows alatt a php -f parancsot futtassam le a fájllal. A fájl meg van. A pre-commit hook-ba bele írtam és mégsem fut le, csak kiírja, hogy "php -f fájlnév". Hol rontom el?
■ Olvastam itt egy jó a cikket a gitről, ehhez kellene segítség. Gitem meg van és van phpunit is. Létrehoztam a phpunit futtatásához egy scriptet, a következőt használtam fel: Git és phpunit. Ebben leírja, hogy windows alatt a php -f parancsot futtassam le a fájllal. A fájl meg van. A pre-commit hook-ba bele írtam és mégsem fut le, csak kiírja, hogy "php -f fájlnév". Hol rontom el?
Statikus tábla tárolása adatbázisban vagy talán jobb xml-ben?
Helló mindenki!
Egy elég fura kérdésem lenne hozzátok, és kíváncsian várom válaszotok:
Lehet nem túl jól fogalmaztam hogy statikus tábla, de lényegében egy olyan db tábláról lenne szó, ami sosem változik.
A LEGO szettek és a LEGO alkatrészek közötti kapcsolatot hivatott tárolni, azaz melyik szettben melyik LEGO alkatrész van, és abból hány darab.
Ennek megfelelően ennyi a tábla tartalma: set_id, part_id, quant
Na most a bajom a következő: átlagba minden szettben van minimum 60 féle alkatrész, tehát egy szettnél akkor ez 60! bejegyzést jelent. Úgy hogy a szettek töredéke sincs még lementve ebben a formában, már így is van ebben a táblában több mint 94000 bejegyzés!! Ez max. a szettek 10%!
A másik része a dolognak, ez sosem változik. Egyszer elmentem, és kész. Onnan már csak néha lekérem, ha a látogató meg akarja tekinteni az alkatrészlistát. Tehát tényleg egy tök statikus dolog.
Az jutott eszembe, mi lenne ha simán xml fájlokban tárolnám ezeket. Mégpedig úgy, hogy a szett száma a fájlnév, pl.: 8052.xml, és akkor két dolgot mentenék bele, part_id és quant. Ez így kb 6000 fájl, és csak annyit kell néznem, hogy $setId.".xml" van-e vagy nincs :)
Szerintetek ezzel kímélném a db-t?
Így is van benne jócskán adat (már most is több mint 10Mb :) )
Előre is köszi a véleményeteket
■ Egy elég fura kérdésem lenne hozzátok, és kíváncsian várom válaszotok:
Lehet nem túl jól fogalmaztam hogy statikus tábla, de lényegében egy olyan db tábláról lenne szó, ami sosem változik.
A LEGO szettek és a LEGO alkatrészek közötti kapcsolatot hivatott tárolni, azaz melyik szettben melyik LEGO alkatrész van, és abból hány darab.
Ennek megfelelően ennyi a tábla tartalma: set_id, part_id, quant
Na most a bajom a következő: átlagba minden szettben van minimum 60 féle alkatrész, tehát egy szettnél akkor ez 60! bejegyzést jelent. Úgy hogy a szettek töredéke sincs még lementve ebben a formában, már így is van ebben a táblában több mint 94000 bejegyzés!! Ez max. a szettek 10%!
A másik része a dolognak, ez sosem változik. Egyszer elmentem, és kész. Onnan már csak néha lekérem, ha a látogató meg akarja tekinteni az alkatrészlistát. Tehát tényleg egy tök statikus dolog.
Az jutott eszembe, mi lenne ha simán xml fájlokban tárolnám ezeket. Mégpedig úgy, hogy a szett száma a fájlnév, pl.: 8052.xml, és akkor két dolgot mentenék bele, part_id és quant. Ez így kb 6000 fájl, és csak annyit kell néznem, hogy $setId.".xml" van-e vagy nincs :)
Szerintetek ezzel kímélném a db-t?
Így is van benne jócskán adat (már most is több mint 10Mb :) )
Előre is köszi a véleményeteket
május 6
Bad request vagy access denied?
Szerintetek olyan esetben, amikor az illetőnek nincs joga az adott művelethez és mellette még formailag hibás kérést is küld, akkor melyik hibaüzenetet adjam vissza neki?
Ha a business logic felett ellenőrzöm a jogosultságot, akkor a bad request a könnyebben megvalósítható, ha a representation felett ellenőrzöm a jogosultságot, akkor az unauthorized a könnyebben megvalósítható. Vajon biztonsági kockázat e, hogy először a formai hibákat ellenőrzöm, és csak utána a jogokat?
■ Ha a business logic felett ellenőrzöm a jogosultságot, akkor a bad request a könnyebben megvalósítható, ha a representation felett ellenőrzöm a jogosultságot, akkor az unauthorized a könnyebben megvalósítható. Vajon biztonsági kockázat e, hogy először a formai hibákat ellenőrzöm, és csak utána a jogokat?
