Być może sami wykombinowaliście większość o czym dzisiaj przeczytacie, a może jednak nie…

1. Odwołania do metod statycznych klasy będącej w przestrzeni nazw. Nie możemy sobie od tak wywoływać metod klasy. Trzeba ją najpierw zarejestrować poprzez registerClass():

$smarty->registerClass('Logger', '\My\Beautiful\Logger');

a następnie w szablonie:

{Logger::logReport()}

2. Przetwarzanie szablonów bezpośrednio ze stringa. Czasami przechowujemy kawałki szablonów w zmiennych i chcemy zwrócić wynik ich przetwarzania do zmiennej. Nic prostszego:

$result = $smarty->fetch('string:My name is {$name}');

3. Ładne grupowanie dużych liczb po 3 znaki.

{1000000|number_format:0:'':' '} zł

Da nam wynik 1 000 000 zł

4. Skrócony zapis tworzenia zmiennej w szablonie. Wynik wywołania metody przypiszemy do zmiennej $my_var. Konieczne jest zachowanie kolejności: assign idzie drugie, nazwa zmiennej w „podwójnych pazurkach”:

{$object->method() assign="my_var"}

5. Tworzenie tablic asocjacyjnych w szablonie. Nie wiedzieć czemu zapis Smartowi nie pasuje:

{assign var="my_arr" value=array('a' => 'aa', 'b' => 'bb')}

należy użyć sposobu znanego z tworzenia tablic w PHP 5.4:

{assign var="my_arr" value=['a' => 'aa', 'b' => 'bb']}

6. Bieżąca data. To oczywiste, ale może komuś umknęło:

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...

…a dokładniej to mowa o ECMAScript 5 i jednej z ważniejszych nowości, które wprowadza do ulubionego języka programistów :-) Mowa oczywiście o trybie ścisłym (ang. Strict Mode). Czym jest owy tryb i dlaczego warto go używać, a także kiedy nie używać? Tryb ścisły, jak mówi sama nazwa, jest ograniczonym wariantem języka JavaScript. Oznacza to, że [...]

zaprojektujmy coś...

Kiedy przeprowadziliśmy już analizę i wiemy, co klient chce abyśmy zrealizowali, wiemy, czego nie chce i obie strony rozumieją co i jak ma działać, możemy ruszać dalej, czyli przełożyć wymagania na coś, co lepiej pasuje do naszego obiektowego świata:)Jednym zdaniem - pora na zaprojektowanie naszej aplikacji. Czytaj więcej »

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.

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 zp8497586rq

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ę.

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/