Archívum
május 17, 2014
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>
Buzzword-free Bounded Contexts
Miért hasalnak el az átlag szoftverek már a tervezés szakaszában
■ május 15
Kiradírozható múlt: érkeznek az első törlési kérések a Google-höz
A személyiségi jogok nevében visszamenőlegesen felszámolható a sajtószabadság
■ Megnehezítendő az adathalászok dolgát, a Chrome az URL-ek nagy részének elrejtésével kísérletezik
A „szép URL” hattyúdala
■ Structure and Interpretation of Computer Programs
Antik könyv a programozásról
■ május 14
Website Deployment: Let Us Count The Ways!
Összefoglaló néhány webes deploy eszközről
■ 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 ?
