Kiedy natknąłem się na ten projekt, nie mogłem uwierzyć, że czysty CSS daje takie możliwości. Okazuje się, że przy odrobinie wysiłku możemy stworzyć “wykręcony” napis, a następnie pobrać kod HTML/CSS pozwalający na osadzenie tego napis na naszej stronie. Zero obrazków, zero JavaScrript, czysty CSS.
Oto próbka możliwości CSS3Wrap.
Więcej informacji na temat CSS3Wrap znajdziecie na stronie projektu – csswarp.eleqtriq.com
Znacie Lucynę? Podobno jest najlepsza w tym co robi. Jeśli wykażemy się odrobiną cierpliwości i zrozumienia, jest w stanie zrobić dla nas dosłownie wszystko. Można się spotkać z niepochlebnymi uwagami kierowanymi pod jej adresem, jednak kilka godzin spędzonych razem pozwoliło mi uznać te opinie za mocno przesadzone. Wprawdzie poznanie jej zajmuje sporo czasu i dopasowanie się do jej humorów nie należy do najprzyjemniejszych doświadczeń, warto jednak się poświęcić, ponieważ zaowocuje to w przyszłości.
Lucyna, a dokładniej rzecz ujmując, Zend_Search_Lucene, jest silnikiem wyszukiwania w całości napisanym w PHP. Wywodzi się z projektu Apache Lucene, jednak niewiele ma z nim wspólnego. Pozwala ona na indeksowanie różnych treści do postaci wspólnego indeksu, na którym później można wykonywać zapytania zwracające pożądane treści.
Wszystko zaczyna się od stworzenia indeksu.
Kanał ATOM
$index = Zend_Search_Lucene::create('/sciezka/do/indeksu');
We wskazanej lokalizacji przechowywane będą zaindeksowane dane. Powyższy kod wystarczy wykonać tylko raz, ponieważ jak już indeks zostanie stworzony, możemy się do niego odwoływać jedynie przy pomocy metody open.
$index = Zend_Search_Lucene::open('/sciezka/do/indeksu');
Utworzony wcześniej indeks możemy wypełnić dokumentami. Dokument stanowi najmniejszy element indeksu. Można go porównać do pojedynczego wiersza w tabeli w bazie danych. Podobnie jak wiersz, składa się on z pól przechowujących konkretne informacje. Jeśli zaindeksujemy listę filmów, wówczas pojedynczy dokument będzie odpowiadał jednemu filmowi, a pola szczegółom tego filmu, np. tytuł, reżyser, rok produkcji, itd.
W przypadku Zend_Search_Lucene każde pole dokumentu posiada własny typ. Dostępnymi typami są:
Tworzenie dokumentów i uzupełnianie ich danych jest niezwykle proste.
$index = Zend_Search_Lucene::open('/sciezka/do/indeksu');
$doc = new Zend_Search_Lucene_Document();
$doc->addField(Zend_Search_Lucene_Field::keyword('data_dodania', '2011-02-03'));
$doc->addField(Zend_Search_Lucene_Field::text('tytul', 'Hello world!'));
$doc->addField(Zend_Search_Lucene_Field::unStored('tresc', 'duzo tekstu...'));
$doc->addField(Zend_Search_Lucene_Field::unIndexed('komentarz_autora', 'jest dobrze'));
$index->addDocument($doc);
Jeśli chcielibyśmy zaindeksować większą ilość danych, wystarczy, że nowe dokumenty będziemy tworzyć i dodawać do indeksu w pętli iterującej po tych danych.
Stworzyliśmy indeks, wypełniliśmy go danymi, pora na wyszukiwanie. W tej dziedzinie Lucyna jest wyjątkowo elastyczna i oferuje szereg zabawek do przeszukiwania indeksu. Począwszy od parsowania przekazanego ciągu na dedykowanych klasach kończąc.
Zacznijmy od parsowania. W tym wariancie Lucyna zdaje się w zupełności na doświadczenie osoby korzystającej z wyszukiwarki.
Witam w drugiej części cyklu „Język Scala dla programistów PHP”. Dzisiaj weźmiemy pod lupę jedno z podstawowych zagadnień każdego języka programowania – strukturę jego kodu.
Każdy język programowania, posiada pewne archetypy, które pozwalają nam systematyzować nasz kod i czynić go czytelnym. Elementami takimi w językach proceduralnych są procedury i funkcje. Języki funkcyjne posiadają funkcję i przestrzenie nazw. Języki obiektowe – klasy i paczki.
Język Scala jako język wieloparadygmatowy posiada trzy główne elementy strukturyzujące kod – paczki, klasy i funkcje. Jednak w przeciwieństwie do „klasycznych modeli obiektowych” znanych chociażby z Javy czy PHP, oprócz „zwykłych” klas, mamy jeszcze trzy ich odmiany. Klasy w Scali dzielą się na:
Poniżej postaram się pokrótce omówić każdy rodzaj klasy wraz z kontrprzykładem z PHP/i lub Javascriptu.
Klasa:
class SampleClass(foo: Int, bar:Double) {
private var _foo = foo;
private var _bar = bar;
def showFooAndBar: String = {
return foo.toString + " i " + bar.toString;
}
}
Standardowe klasy w Scali definiowane są podobnie jak w Javascripcie – przez konstruktor. Jak widzimy na załączonym przykładzie mamy zdefiniowany konstruktor klasy SampleClass, który przyjmuje jako argumenty zmienne foo i bar. Argumenty te przypisywane są do prywatnych zmiennych _foo i _bar. Konstruktor ten definiuje również jedną metodę – showFooAndBar , który zwraca obiekt typu String. Dla porównania kontrprzykład w javascripcie:
function SampleClass(foo, bar) {
var _foo = foo
var _bar = bar
this.showFooAndBar = function(){
return _foo + ' i ' + _bar;
}
}
Użycie:
Scala:
object Main {
def main(args: Array[String]): Unit = {
val sample = new SampleClass(1,5.5)
println(sample.showFooAndBar)
}
}
Javascript:
var sample = new SampleClass(1, 5.5) console.log(sample.showFooAndBar())
Jak widzimy podobieństwo jest uderzające. Dla tych, dla których model obiektowy Javascriptu jest okropny i niezrozumiały mam dobrą wiadomość – mimo podobieństwa w tym przypadku kodu jednego i drugiego języka, Scala nie bazuje na prototypach.
Jarrod Nettles w niedawnym wpisie na php.internals zgłosił propozycję wprowadzenia modyfikatorów widoczności dla klas. Propozycja postuluje, by podobnie jak w przypadku elementów klas (właściwości i metod), mieć możliwość ograniczenia widoczności klasy względem przestrzeni nazw. Jak miało by się to odbywać ? Przed deklaracją klasy można by umieścić jedno ze słów kluczowych – public, internal, lub private (albo public, protected, private):
private class Foo {
private $_bar;
public function bar(){
return $this->_bar;
}
}
Działanie:
Foo\Bar, to możemy ją również używać w Foo\BazFoo\Bar to mogę ją tylko używać w Foo\Bar i nigdzie indziejNie jest to ostateczny kształt propozycji, ponieważ, cały czas trwają dyskusje na ten temat na liście. Także to co napisałem może się jeszcze zmienić. Natomiast generalnie widać, że raczej większość osób jest jej przychylna. Na pewno ten „ficzer” będzie pomocny dla autorów frameworków, którzy będą mogli bardziej precyzyjnie kształtować API swoich bibliotek. Nie trudno również zauważyć, że propozycja ta jest tak naprawdę ściągnięta z języków typu C# i Java, gdzie takie modyfikatory dostępu już istnieją od dawna. Ze swojej strony mogę tylko powiedzieć, że osobiście wole model obiektowy oparty na bardziej ogólnym mechanizmie (świetnym przykładem jest Javascript).
Jestem ciekaw co Wy myślicie o tej propozycji ?
Ostatnio miałem nie powtarzalną okazję przeanalizować prezentacje przygotowane na Symfony Live 2011 – konferencję Symfony która odbyła się w Paryżu. Na listę prezentacji udostępnionych na slideshare natrafiłem poprzez post @caefer-a oraz post Jakuba Zalasa. Postanowiłem napisać kilka słów o slajdach które przeczytałem.
Prezentacja opisuje podstawowe koncepcje stojące za nowym frameworkiem z SensioLab. Nauczyłem się z niej wiele o kontenerze wstrzykiwania zależności oraz komponentach do cachowania no i oczywiście dowiedziałem się dlaczego Symfony2 rządzi.
Myśle żę Apostrophe może być alternatywą dla Drupala czy WordPressa. Jest to całkiem porządny CMS oparty i napisany na symfony 1.4. Polecam go szczególnie tym programistom PHP którzy mają dość “poezji” Drupala i WordPressa. Mam nadzieję że będę mógł poznać i nauczyć się tego CMF-a w najbliższym czasie.
O nowych formularzach w Symfony 2 czytałem już wcześniej, jednak pierwszy raz spotkałem się w tej prezentacji z obiektami Configa w Symfony 2. Taki obiekt może być obsłużony przez mechanizm wstrzykiwania zależności (w przeciwieństwie do obiektu formularza). Wstrzykiwanie zależności jest bardzo dobym mechanizem który może pomóc nie powtarzać kodu, jednak nie wiem czy ma to sens w wypadku bardzo scustomizowanego formularza. Myśle jednak że może poprostu potrzebuje się z tym oswoić i nabrać praktyki.
Pierwszy raz słyszałem o Assetic-u. Bardzo mi się spodobał. Jest to optimizer do wszystkich rzeczy związanych z frontend-em czyli minimalizacji stylów, javascriptów oraz całej reszty. Ma on bardzo dobrą integrację z Symfoniowym Twigem przez TwigExtension. Napewno przyjrzę się Assetic-owi bliżej.
Nie widziałem jeszcze wszystkich prezentacji z Symfony Live. Uważam że takie slajdy są ogromną bazą wiedzy, jednak uczestnictwo w konferencji daje jeszcze więcej – nawet gdy wykłady nie są interesujące lub są dla nas oczywiste. Konferencja daje nam możliwość wymiany doświadczeń i poznania innego spojrzenia niż nasze – moim zdaniem to jest to bardzo wartościowe, dlatego polecam wszystkie konferencje. Żałuję tylko tego że nie mogłem wziąść udziału w Symfony Live, no nic może następnym razem.
Zgodnie z obietnicą dzisiaj zajmiemy się warstwą prezentacyjną ASP.NET MVC, czyli widokiem. Do czasu wydania trzeciej wersji ASP.NET MVC sprawa była prosta. Mieliśmy jeden mechanizm odpowiedzialny za renderowanie widoku i musieliśmy się go trzymać. Wprawdzie można było napisać własny mechanizm widoku, jednak podobnie jak w Zend Frameworku mija się to z celem. Napisałem mieliśmy, ponieważ wraz z premierą ASP.NET MVC 3, ukazał się nowy silnik widoków o nazwie Razor, oferujący jeszcze więcej możliwości.
Zaczniemy od “starego” silnika, czyli ASPX, znanego z klasycznego ASP.NET. W silniku tym dane przekazujemy poprzez obiekt ViewData, posiadający typ ViewDataDictionary. Obiekt typu ViewDataDictionary można porównać do tablicy asocjacyjnej znanej z PHP. Dla zadanego klucza przypisywana jest wartość. Zobaczmy jak to działa na przykładzie. W kontrolerze przypisujemy wartość do klucza.
public ActionResult Index()
{
ViewData["klucz"] = "wartość";
return View();
}
A w widoku wyświetlamy jego zawartość.
<div>
<%= ViewData["klucz"] %>
</div>
Jak widzimy “na załączonym obrazku”, wyświetlanie treści odbywa się dzięki czemuś, co przypomina short tag znany z PHP. Wraz z pojawieniem się czwartej wersji .NET, programiści otrzymali drugi short tag, zawierający zamiast znaku równości dwukropek. Różnica w działaniu obu short tagów jest zasadnicza. W pierwszym przypadku (znak równości) kod HTML zostanie zinterpretowany, a następnie wykonany. Nie muszę chyba pisać jak bardzo jest to niebezpieczne w przypadku treści dostarczanej przez użytkownika. Problem ten rozwiązuje zapis z dwukropkiem, który zamienia krytyczne znaki na encje HTML, przez co na ekranie wyświetli się tekst w takiej formie, w jakiej został przekazany do ViewData.
Opisany powyżej sposób sprawdza się doskonale w przypadku typów prostych. Niestety w przypadku modelu nie wiemy co znajduje się w ViewData. Jak już wspomniałem ViewData jest typem słownikowym, w którym klucz posiada typ string, a wartość object. Powoduje to, że w przypadku własnych typów musimy w widoku rzutować wartość do pożądanego typu. Na szczęście ViewData posiada specjalną właściwość nazwaną Model, która w połączeniu z typem widoku jest w stanie przechować właściwy typ obiektu.
Warto w tym miejscu warto na chwilę się zatrzymać i poznać sposób w jaki dane trafiają do widoku. Każdy widok (jak wszystko w ASP.NET MVC) posiada swój typ. W najprostszym scenariuszu widok dziedziczy po prostu po klasie ViewPage, przez co wspomniana wcześniej właściwość Model jest niczym innym jak standardowym obiektem (typ object). Widok taki nazywany jest luźno typowanym (loosely typed).
W opozycji do luźno typowanego widoku stoi widok silnie typowany (strongly typed), który również dziedziczy po klasie ViewPage, przy czym klasa ta jest klasą generyczną, gdzie typem jest nasz model. W takim widoku mamy dostęp do “prawdziwej” klasy wraz z całym dobrodziejstwem inwentarza.
Trzecim sposobem jest skorzystanie z nowego typu dostępnego od .NET 4 – dynamic jako typu w generycznej klasie ViewPage. Sposób ten pozwala na dostęp do właściwości i metod modelu w czasie wykonywania (tak jak w PHP).
Jeśli mamy zdefiniowaną klasę modelu, możemy przekazać ją do widoku na dwa sposoby. Pierwszy znamy już z wcześniejszego opisu – jako właściwość Model obiektu ViewData.
Załóżmy następujący model.