Niezalogowany [ logowanie ]
Subskrybuj kanał ATOM Kanał ATOM    Subskrybuj kanał ATOM dla tagu framework Kanał ATOM (tag: framework)

Autor wpisu: stormfly, dodany: 30.12.2015 13:32, tagi: php, framework

Kto nie spotkał się z opinią, że do prostej strony framework nie jest potrzebny i czysty php wystarczy – zostawia komentarz ;) Tytułowe pytanie można odwrócić, co nam przeszkadza podłączenie frameworka? Spróbujmy zebrać odpowiedzi jakie padają: 1) niepotrzebne dziesiątki/setki...

Autor wpisu: matipl, dodany: 01.10.2015 12:52, tagi: php, framework, symfony

Londyn - Big Ben & London Eye W tym roku udało mi się wybrać na konfernecję Symfony Live London 2015, która odbyła się 18 września (+ warsztaty dzień wcześniej) dzięki przychylności losu… Całe spotkanie odbywało się w Queen Elizabeth II Conference Centre, czyli w samym centrum Londynu. Pod nosem metro (Westminster), jak i moc atrakcji turystycznych (Big Ben, London Eye, pałac w Westminter itd.). Mocno na plus, szczególnie, że cena dla Anglików nie była wygórowana (£210.00).

Lasery i algorytmy

Prelekcją otwierającą była „Getting artistic with code”, którą zaprezentował Seb Lee-Delisle. Prezentacja była zupełnie inna niż wszystkie, do których się przyzwyczaiłem na konferencjach technicznych. Na początku zapowiadał się niesamowity gniot, po tym jak Seb pokazał kawałek JavaScript’u z OnMouseOver – od razu pomyślałem, sobie że to przecież kod sprzed 15 lat… Ale Seb chciał pokazać w jaki sposób można tworzyć sztukę, być Artystą używając do tego czystego języku (JavaScript) i zmyślnych algorytmów. Można tworzyć – bawiąc się. Ostateczny efekt był piorunujący i uważam, że każda konferencja powinna rozpoczynać się podobnym wystąpieniem – niby nie związany z tematem, a jednak… Seb Lee-Delisle specjalizuje się obecnie w pokazach laserowych. Poniżej jego algorytmy podczas Smashing Conference w 2014 roku – połączenie algorytmów i laserów:

Później już było konkretnie. Podczas prelekcji „Building a Pyramid: Symfony Testing Strategies” Ciaran McNulty za pomocą piramidy potrzeb Maslowa zaprezentował jak ważne są testy jednostkowe, a dopiero później znaczące są testy integracje i UI. Mam nadzieję, że niedługo pojawią się nagrania z konferencji.

Doctrine 2

Dużym zaskoczeniem były natomiast słowa Benjamina Eberlei podczas „Doctrine 2: To Use Or Not To Use”. Powiedział, że Doctrine jest tworzony zgodnie z zasadą Pareto (80/20), czyli dla 80% przypadków użycia. W ramach tych 80% przypadków Benjamin wymienił CRUD, Symphony Validator + Forms, natywny SQL i dla tych zastosowań Doctrine to wręcz idealne rozwiązanie. Niestety Doctrine nadal nie radzi sobie z dużą ilością zapisów, ma problemy z wydajnością i złożonymi zapytaniami (raporty itp.). Jak również powinniśmy unikać ORM dla batching processing.

Jak również przypomniał, że wywołanie flush() niszczy wiązania w entity / $query->iterate(), przez to powoduje spore obciążenia serwera gdy robimy flushowanie w pętlach etc. Dlatego pamiętajmy, aby wykonywać tą operację tylko po zakończeniu wszystkich operacji.

Pamiętajmy również, że kompleksowe zapytania DQL z duża ilością wiązań (JOINs) są bardzo wolne i należy ich unikać. W takich wypadkach lepiej zrobić dedykowany model View/Read, który operuje tylko na wybranych polach ze wszystkich JOINs.

Very Good: CRUD (& Symphony Validator + Forms) Good: DDD Lite with coupling to Doctrine/DB Okies: DDD (decoupling requires works) Bad: high write throughput

Summary 80%: CRUD, Lazy, Native SQL Risk: Performance Problems, Unsolvable Edge Class, High Coupling, Complexity

Symfony 3.0

Prelekcję końcową wygłosił Fabien Potencier. Po auto-reklamie produktów Blackfire.io, przedstawił małe podsumowanie prac nad Symfony 3.0 (praktycznie to 2.8, która zostanie podbita do 3.0). Fabien podkreślił, że coraz więcej projektów tworzonych jest na komponentach Symfony i to bardzo go cieszy. Niedługo zobaczymy oparte na Symfony:

  • Drupal 8
  • phpBB
  • prestaShop

Wspomniał również, że obiecanie kompatybilności wstecznej w całej linii Symfony 2.x było wielką pomyłką jego i zespołu. Dużo prac ich to kosztowało przez co nie mogli iść do przodu z nowościami. W wersji 3.0 również było sporo takich problemów, dlatego teraz będzie fixowanie w x.y.(z+1), a nie jak wcześniej w x.y .

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

Autor wpisu: JoShiMa, dodany: 27.06.2015 00:20, tagi: framework, jquery, php, skrypty

Z podpowiedziami w polu tekstowym formularza uporałam się szybko. W Yii to naprawdę jest proste. Trudności zaczęły się gdy trzeba było zastosować autouzupełnianie do pól formularza, które są generowane automatycznie po załadowaniu strony za pomocą javascript. W tym wypadku widget nie pomoże i trzeba zadziałać inaczej. Dołączanie skryptów JS W pierwszej kolejności należy zadbać o […]

Autor wpisu: JoShiMa, dodany: 24.06.2015 23:52, tagi: framework, php, skrypty

Z braku lepszego zajęcia programistycznego pisze pracuję nad pewnym niekomercyjnym (przynajmniej na razie) projektem realizowanym w oparciu o framework Yii. Nie będę ukrywać polubiłam go. Funkcjonalność serwisu pomaga mi dopracować grupa przyszłych użytkowników, którzy już przebierają nóżkami nie mogąc się doczekać realizacji. Padła sugestia, która prędzej czy później musiała się pojawić, bo była po prostu […]

Autor wpisu: Pyton, dodany: 04.03.2015 15:37, tagi: php, framework

Wraz z ukazaniem się Laravel 5 dostaliśmy z marszu kilka udogodnień m.in. kontrolery do logowania, rejestracji. To wszystko zostało okraszone przez Bootstrap. Ale co jeśli nie chcemy tego wszystkiego, tylko czystą aplikację?

Nic prostszego. Wystarczy jedna komenda:

php artisan fresh

I już pozbyliśmy się wszystkiego co przyszło z nowym projektem.

Autor wpisu: Wojciech Sznapka, dodany: 27.04.2014 18:20, tagi: framework, mvc, php

Lately I see perilous situation in software development area. There are plenty of good devs so much bounded to tools. By tools, I mean mostly frameworks. I would like to elaborate a bit about that, but those are my personal opinions and they aren’t here to offend anyone.

First of all, we all need to admit, that quality of modern MVC framework raised a lot, comparing with state of things few years ago. Speaking about PHP – at the time, when I attracted my attention to this language, there were pure wilderness. We did not have any strong framework (unlike Ruby On Rails, which were sine qua non choice for Ruby web development). That caused multiple projects development, some of them are dead now (or should be), some hasn’t got good market adaptation and some of them are industry leaders at the moment (Symfony and Zend).

On the other hand, there’s huge temptation to write own frameworks, ignoring the great work of community. That has some advantages, in case you know exactly what you’re doing. Only one good reason for me is performance concerns. But still, doing everything by hand proves lack of understanding of tools and leads to giant problems with system maintenance. For me, it’s hard to imagine how one could create a complex system without usage of good framework. What’s more, its economically unreasonable to recreate the code, that already exists.

Alright, it’s clear –  applications which will serve their purpose are way easier to be created with modern framework. The choice isn’t easy (as well as choice of language), but if you ask me, I’ll say: pick the one you feel the most comfortable with and which is built on top of best design patterns. A framework won’t do the job by its own, though. And this is the point I’d like to make: don’t be bound to the framework. The best quote to reflect this point of view is:

The architecture of an accounting app should scream “accounting” not Spring & Hibernate. Robert C. Martin via https://twitter.com/unclebobmartin/status/118365858581069824

By decoupling from framework (see Jakub Zalas slides) you’ll benefit in multiple ways: your code will be loosely coupled, easier to understand, readable, testable and most important: it will be robust. If for some reason, you’ll have to change framework (because yours isn’t supported any more and super 3rd edition of famous framework comes to general availability), you’ll spend considerably less amount of time to migrate to new libraries.

A thing to remember is, that good software design practices, such as design patterns or SOLID principles, exists for years now. They are applied in all software languages and you’ll find similar concepts both in Java Spring and PHP Symfony. Frameworks, on the other hand comes and goes. In 3 years from now, there won’t be Symfony2 or Zend Framework2, but your code will be still alive and need to be maintained. It’s your choice, if it be completely dependent on framework or if it will rely on proven patterns.

I strongly encourage to read and apply philosophy of Domain Driven Design. It’s better to focus on a core domain and reflect business needs by modelling them with code. Once you’ll be focused on domain, you’ll start to see that framework is only implementation detail and you’ll stop calling yourself Symfony Developer or Zend Developer, but rather Software Developer.

Autor wpisu: JoShiMa, dodany: 26.09.2013 22:47, tagi: framework, php, skrypty

Miało być prosto. Dokumentacja Yii przekonuje, że wystarczy skopiować pliki na serwer, uruchomić jeden z nich za pomocą wiersza poleceń, podając odpowiednie parametry i już mamy szkielet aplikacji. Kuszące, bo w Kohana trzeba strukturę katalogów aplikacji sobie ręcznie stworzyć. Strona, którą muszę uruchomić ma powstać na serwerze hostowanym przez AZ w niezbyt wypasionej opcji. Sęk [...] Related posts:
  1. Yii – początek
Wszystkie wpisy należą do ich twórców. PHP.pl nie ponosi odpowiedzialności za treść wpisów.