Autor wpisu: cojack, dodany: 26.11.2011 19:39, tagi: php
Ostatnio zacząłem pracę nad API Facebooka i moim zadaniem było rozpracowanie tego api, takie tam. Ale doszło w reszcie do acziwmentów na facebugu. Jeden wpis w google how to, i wio ogień, jedziemy. Poszło łatwo, dokumentacja fajna, przejrzysta, wszystko ładnie opisane: link no ale gdyby wszystko poszło bez problemu nie byłoby tego wpisu…
Facebug
Nie bez kozery w żargonie programistów ta nazwa nabiera coraz silniejszego znaczenia. Kto pracuje z API tego serwisu społecznościowego ten to rozumie. Facebook jest teraz w fazie wprowadzania nowego API o nazwie kodowej Graph (wow how f***g awesome it’s?!). Wracając do meritum sprawy, po wywołaniu rejestracyjnego linka z acziwmentem ni stąd ni zowąd dostawałem błąd: „(#3502) Object at achievement URL is not of type game.achievement”, o którym już pisałem wcześniej na forum php: link, niestety nikt chyba wcześniej nie miał problemu z tym (albo miał i się nie podzielił, who care?). Sytuacja doprowadzała mnie do frustracji, gdyż po użyciu debuggera: link nie zwracał mi żadnego błędu związanego z opengraph, a błąd mówił o czymś innym. Bądź tu mądry i pisz wiersze…
Rozwiązanie problemu
Otóż przypadkiem(?) parę razy udało mnie się zarejestrować te acziwmenty, zachodziłem w głowę jak ja to zrobiłem. Maluśka retrospekcja i olśniło mnie co takiego zrobiłem. Otóż proces jaki należy wykonać przed przystąpieniem do zarejestrowania acziwmentu jest taki:
Wchodzi na stronę debbugera: link
Wklepujemy link do naszego acziwmentu, klikamy debug (wow!), teraz na samym dole po poprawnej analizie naszego pliku powinna się znajdować sekcja: „Adresy URL” (tia mam po polskiemu) i jest sobie jakiś pierwszy link:
Graph API: http://graph.facebook.com/blablabla
klikamy na ten link, otworzy nam się stronka z wyplutym jsonem, i dawaj, po tym zabiegu możemy już wykonać poprawnie proces rejestracji acziwmentu bez żadnego problemu!
Słów kilka na zakończenie
3 dni się z tym ścierwem męczyłem…
Autor wpisu: bastard13, dodany: 25.11.2011 15:08, tagi: php, oop
ciągle o tym samym
W dzisiejszym wpisie kontynuuje wątek z poprzedniego wpisu, a więc nadal będzie o metodach:)Dzisiaj zbiór wszelkich różnych rzeczy dotyczących metod, czyli trochę informacji, a trochę dobrych praktyk, które warto przestrzegać, aby z kodem przyjemniej się pracowało:)Czytaj więcej »Autor wpisu: batman, dodany: 24.11.2011 08:00, tagi: zend_framework
W ramach szukania oszczędności czasu podczas tworzenia nowych aplikacji opartych o Zend Framework, zauważyłem iż najczęściej kopiowanym przeze mnie kodem jest część administracyjna, szumnie nazywana CRUD. Bardzo często jedyną zmianą jaką musiałem wprowadzić do kodu, była modyfikacja klasy modelu idąca w parze z dopisaniem nowej klasy formularza oraz ewentualne kosmetyczne zmiany w widokach. Mimo iż powyższe czynności nie są skomplikowane, marnują czas i dodatkowo generują sporo niepotrzebnego kodu w postaci kontrolerów i modeli. Z poczynionych obserwacji wyciągnąłem wnioski i napisałem prostą i funkcjonalną zarazem aplikację opartą o Zend Framework, która nie wymaga tworzenia zbędnych klas.
UniversalZF – konwencje
Aplikacja jest mieszanką konwencji oraz konfiguracji. Z jednej strony należy trzymać się założeń poczynionych przez autora (czyli mnie), z drugiej istnieje możliwość wprowadzenia ograniczonych zmian do mechanizmu dzięki konfiguracji przechowywanej w application.ini (lub odpowiedniku).
Najwięcej założeń poczyniłem w stosunku do bazy danych:
- nazwy tabel są jednowyrazowe, pisane bez podkreślników oraz bez użycia camelCase, np user, page, book, products, itd
- nazwy tabel odpowiadają dynamicznie obsługiwanemu kontrolerowi
- kolumna będąca kluczem głównym nazywa się id
- wszystkie tabele znajdują się domyślnym schemacie (w PostreSQL jest nim public)
Kolejnym wymogiem jest nazwa klasy formularza służącego do dodania/edycji rekordu. Musi ona odpowiadać nazwie tabeli w bazie danych, czyli dla user będzie nazywała się Application_Form_User. Ponadto nazwy pól w formularzu muszą odpowiadać nazwom pól w bazie danych.
I to wszystko. Jeśli powyższe warunki zostaną spełnione, będzie można korzystać z UniversalZF.
UniversalZF – konfiguracja
W przypadku konfiguracji, istnieje możliwość zdefiniowania:
- kontrolera automatycznie obsługiwanego przez UniversalZF
universal.page[] = "user"
W powyższym przykładzie kontrolerem tym będzie user. Oznacza to, iż tabela w bazie danych nazywać się musi user, a klasa formularza Application_Form_User.
- nazw kolumn pomijanych w widoku prezentującym tabelę z danymi
universal.page.user.skipCols[] = "id" universal.page.user.skipCols[] = "password"
- widoku jaki wyrenderuje się dla konkretnej akcji
universal.page.user.view.index = "user/index.phtml"
Jak to działa?
Za wszystko odpowiedzialny jest plugin przechwytujący żądanie i sprawdzający, czy dany kontroler należy obsłużyć przy pomocy UniversalZF. Jeśli tak, na podstawie nazwy kontrolera tworzony jest obiekt modelu oraz obiekt DbTable, przy czym obiekt DbTable tworzy się dopiero w momencie, gdy jest potrzebny (lazy loading). Resztą zajmuje się kontroler universal posiadający akcje index (listowanie wszystkich danych z tabeli), add i edit (dodanie i edycja danych) oraz delete (usunięcie danych).
Ponieważ universal jest zwykłym kontrolerem, ktoś ciekawski mógłby wpaść na pomysł odwołania się do niego bezpośrednio. Wprawdzie ktoś taki za wiele by nie zdziałał, ale i tak warto takie zapędy ukrócić. W tym celu w pliku konfiguracyjnym znajduje się hash, doklejany w pluginie do parametrów przekazanych do akcji. Jeśli ktoś wejdzie bezpośrednio na kontroler universal, ten rzuci wyjątkiem o niepoprawnym hashu.
Autor wpisu: sokzzuka, dodany: 22.11.2011 15:42, tagi: javascript, php
From some time (2+ years) we can observe a huge explosion of different Javascript frameworks. These frameworks divide mainly into two categories
- UI widgets / DOM manipulation frameworks
- class based type system frameworks
In this post I would like to focus on the latter. Every time is see a new framework of this type popping on the news I tend to ask myself the same question – why ? Why one does write all does frameworks, why people so much need classes in Javascript ?
After some thinking I’ve got to a conclusion, that people need them mainly because they are used to the concept of the „class” and to a typical type system like this found in Java, PHP or „name your favorite mainstream programming language here”. This is understandable, as naturally human beings are resistive to change. Also, some people tend to „not get” what’s going on in the prototypical type system. We cannot also blame them here because it has some quirks and well, no one teaches it in schools ( ;P ).
One may ask himself – do we have an other choices to write clean, readable and understandable code other than using JS frameworks ? I think the answer for this question would be affirmative.
But before we come up for a solution. We must think for a second and summarize what we are trying to achieve. I think that are needs wrap in:
- new object instantiation
- information hiding
- code reuse
- modularization
The thing that some one will miss would be inheritance. Should it be on the list ? I don’t think so. The reason for the lack of inheritance is simple – inheritance has two purposes:
- vertical code reuse – the type lower in the hierarchy inherits behavior from the type higher in it
- signature checking – in statically typed class based languages, polymorphism is achieved through inheritance
we could achieve code reuse by other means in Javascript and as JS has no type checking we don’t need inheritance at all.
For our „no framework JS framework” we will use mainly such features of JS as first class functions and JSON. So behold, some common patterns for our daily JS programming:
//persons modulepersons = (function(){ //private Person object constructor var Person = function(firstName, lastName, birthDate){ var foo = "bar"; var name = function(){ return firstName + " " + lastName; } var age = function(){ var currentYear = (new Date()).getYear() var birthDayYear = birthDate.getYear() return currentYear - birthDayYear } var saySomething = function(){ return foo; } //the methods that will be public return { "name": name, "age": age, "saySomething": saySomething } } //private FitnessAddict object constructor var FitnessAddict = function(firstName, lastName, birthDate, weight, height){ var person = Person(firstName, lastName, birthDate); var bmi = function(){ return weight / (height*height); } var isWeightNormal = function(){ var currentBmi = bmi() if(currentBmi > 25){ return false } if(currentBmi < 18.5){ return false } return true } //we make isWeightNormal method public person.isWeightNormal = isWeightNormal; return person; } //we make the fitnessAddict object constructor public return { "fitnessAddict": FitnessAddict }})()view raw noFrameworkJsFramework.js This Gist brought to you by GitHub.
Usage of the example:
var fa = persons.fitnessAddict( "Bar", "Baz", new Date(1990,5,5), 80, 1.8) fa.isWeightNormal() // truefa.saySomething() // "bar"fa.name() // "Bar Baz"view raw noFrameworkJsFramework2.js This Gist brought to you by GitHub.
The first example proves, that we can achieve all of our goals through simple Javascript, without the need for frameworks. The additional benefit is that, because all is private by default, we improve the „cleanliness” of our API.
Autor wpisu: batman, dodany: 21.11.2011 20:46, tagi: php
Dzisiejszy wpis będzie niecodzienny, ponieważ nie jest to news ze świata IT, konkurs ani stricte techniczny tekst. Dzisiaj poszukiwany, poszukiwana jest specjalista od Magento. Jeśli wiesz co to jest, potrafisz się w tym odnaleźć oraz posiadasz odpowiednio dużo wolnego czasu, wyślij maila na adres ksoklabs [at] gmail [dot] com. W treści maila prześlij przykłady swoich wdrożeń (linki do stron) oraz stawkę godzinową.
Ponieważ to nie ja poszukuję, nie jestem w stanie podać więcej szczegółów. Uzyskacie je pod wskazanym adresem.