Autor wpisu: matipl, dodany: 06.03.2013 17:15, tagi: php
Na własnych maszynach produkcyjnych przeznaczonych pod Web zawsze kompiluję nginx + php. Mimo że „kompilacja” dla niektórych brzmi strasznie jest to tak naprawdę banalnie prosta procedura, tym bardziej jeśli chociaż jeden raz to przeszliśmy.
Niestety nie zawsze mam okazję wdrażać aplikacje/systemy webowe na maszynach przygotowanych przeze mnie, a niektórych adminów nie można po prostu doprosić się o świeżość PHP. Kilka ostatnich projektów były uruchamiane na maszynach gdzie PHP jest zainstalowany z paczki. Niby nic groźnego, a nawet zalecanego przez niektórych Linuksiarzy (stare=bezpieczne), ale np. Debian, CentOS mają paczki z PHP w wersji 5.3.3. Numerek nic Wam nie mówi? Wersja 5.3.3 była wydana 22 lipca 2010 roku! To już prawie 3 lata. W świecie języka, który jest bardzo dynamicznie rozwijany jest to cała dekada.
Nie byłoby w tym nic dziwnego, gdyby jeden z projektów nie korzystał z wbudowanego w PHP SoapClient (moduł libxml). No bo po co dodawać biblioteki zewn. do SOAP jeśli PHP ma to wbudowane? Wszystko działało świetnie, do momentu gdy musiałem wywołać żądanie z drugim parametrem (choice w XSD). SoapClient uparcie twierdził, że WSDL nie pozwala pominąć pierwsze parametru. A gdy był podany pierwszy, to ignorował drugi. Zmiany w XSD pomogły i pojawiło się pytanie gdzie problem?
Koniec, końców okazało się, że w PHP był błąd który został poprawiony w wersji 5.3.18 (z #50997 – SOAP Error when trying to submit 2nd Element of a choice).
Pod tym względem nie do końca rozumiem osoby odpowiedzialne, za akceptację paczek w tych dystrybucjach. Co innego migracja na PHP 5.4, a co innego łatanie poprzedniej wersji (5.3), gdzie nic nowego się nie pojawia. Pod tym względem zawsze lubiłem PLD, gdzie paczki można było spokojnie użyć w wielu przypadkach zamiast kompilowanych wersji (obecnie mają 5.3.21, a aktualny PHP to 5.3.22).
Podsumowując – jeśli programujecie w PHP, lub jesteście administratorami systemu z PHP proszę, pilnujcie czy przypadkiem na php.net nie ma nowszej wersji. Może to zaoszczędzić kilku dni w szukaniu błędu, lub uniemożliwić wykorzystanie luki w PHP, która wyjdzie na wierzch.
Autor wpisu: Kamil Adryjanek, dodany: 06.03.2013 02:23, tagi: symfony2, php, symfony
Symfony2 comes with a very nice validation system and allows us for example to add a constraint to any public method whose cheap viagra name starts with „get” or „is” („Getters”) and not only. In combination with the Validation Groups it is a really powerfull tool. This time i want to show you how to map those errors.
Adding custom method to entity we can add some extra validations for example to address field:
<?php // some entity class /** * Checks if user provides a valid address * * @Assert\True(message = "user.address.invalid") */ public function isAddressValid() { // some logic }
Now this entity will be also checked against extra rules form isAddressValid method. That’s really cool and easy but there was one thing that forced me to choose Callback Validation and its:
$context->addViolationAt('address', 'user.address.invalid', array(), null);
instead of Getters in many cases: i was not allowed to assign errors to specific fields on my object. It means that i couldn’t make these errors display next to a specific field and they were displayed at the top of my form – since Symfony2.1 it’s not a problem any more.
Thank to new error mapping funcionality: „error_mapping” we can now set which method should be mapped to a given field”:
<?php class UserType extends AbstractType { public function setDefaultOptions(OptionsResolverInterface $resolver) { $resolver->setDefaults(array( 'error_mapping' => array( // this line tells Symfony to assign Getter Constraint to address property 'addressValid' => 'address' ), )); } }
Since error_mapping is set, errors will be displayed next to address filed.
We can also use dot for building nested property paths and assign errors to embedded forms: ‚cityValid’ => ‚address.city’ or ‚address.cityValid’ => ‚city’ – depending on our needs.
Ecard Wizard Greeting Card Software zp8497586rqAutor wpisu: vonski, dodany: 03.03.2013 04:17, tagi: javascript
To, że granica między funkcjonowaniem stron internetowych na urządzeniach stacjonarnych a mobilnych coraz bardziej się zaciera, już dawno stało się faktem. Kolejny krok w tym kierunku wykonali panowie Jordan Singer oraz Brandon Jacoby. Napisali oni małą bibliotekę Javascript o nazwie hook.js, która imituje zachowanie znane z urządzeń mobilnych pod nazwą „Pull to refresh”. Jej działanie można przetestować na stronie domowej projektu (usehook.com), skąd również można pobrać bibliotekę.
Autor wpisu: vonski, dodany: 03.03.2013 03:48, tagi: css
Thomas Stachl (@thomasstachl) jest twórcą ciekawej biblioteki o nazwie Slidr.css. Pozwala ona urozmaicić wygląd checkbox-ów na naszej stronie poprzez wyświetlanie ich w formie mini-sliderów. Co jeszcze bardziej ciekawsze, autor rozwiązania nie używa w tym celu ani grama Javascript-u!
Żeby jednak ostudzić entuzjazm, należy dodać, że autor odradza na chwilę obecną używać Slidr-a na stronach produkcyjnych, ponieważ jest on dopiero w fazie eksperymentalnej. Niemniej jednak projekt wydaje się ciekawy.
Więcej szczegółów oraz kod źródłowy można znaleźć na Githubie autora pod adresem http://tstachl.github.com/slidr.css/