Propozycje tematów Opcje

[Nickesh]

Witam, chciałbym rozpocząć dyskusję na temat zaawansowanej obsługi błędów w złożonych aplikacjach obiektowych.
Chodzi o koncepcję (właścwie o wzorzec projektowy) efektywnego i wygodnego debugera dla systemu składającego się z wielu hermetycznych modułów - jak większość "domowych" frameworków, z których żaden dumny autor nie chce rezygnować (IMG:http://forum.php.pl/style_emoticons/default/snitch.gif)
Jest wiele patentów na to, ale zwykle obciążają skrypty tonami kodu.
Ogólnie, topic odpowiadałby na pytanie: "Jak najefektywniej budować wielopoziomową obsługę błędów, tak, żeby się w niej nie pogubić.".

Konkretnie interesuje mnie system, w którym każda klasa ma własny handler i potrafi w ograniczony sposób wpływać na zachowanie całego skryptu. Inne klasy, które z niej korzystają interpretują jej błędy i decydują o tym, jaki mają wpływ na ich własne zachowanie.
Jednocześnie, jak już wspomniałem, rozwiązanie tego typu, że każdą klasę dziedziczymy z jakiegoś przykładowego "errorHandlera" (*kod ponizej) nie przemawia do mnie, bo przy rozbudowanych hierarchiach zawsze trzeba zrzucać ręcznie te błędy na kolejne poziomy - przez kolejne warstwy systemu, np. od jądra, przez kontrolery, widoki, aż do szablonów. Napewno każdy, kto próbował kiedyś pisać spójną rozbudowaną bibliotekę, spotkał się z tym problemem.

[PHP] pobierz, plaintext 
<?php
// Standardowy errorHandler, którego dzidziczą wszystkie klasy w systemie.
// Oczywiście, to tylko najprostszy przykład.
 
class errorHandler {
    private $errors = array();
    
    function isError() {
        return !empty($this->errors);
    }
    
    function lastError() {
        return array_pop($this->errors);
    }
    
    function setError($message) {
        $this->errors[] = $message;
    }
    
    funciton clearErors() {
        $this->errors = array();
    }
}
?>
[PHP] pobierz, plaintext 

Oczywiście proponuję ogólną dyskuskę na ten temat - o szczegółach napisałem tutaj tylko, żeby było wiadomo, o co mi właściwie chodzi (IMG:http://forum.php.pl/style_emoticons/default/snitch.gif)

[nasty]

Witam,

Ostatnio coraz to częściej zdarza mi się mieć wyrzuty sumienia zwiazane z tym czy aby napewno nie zagalopowałem się z projektem systemu, czy nie przesadziłem z modularnością, elastycznością, konfiguralnością, odzielaniem coraz to różniejszych warstw (dla przykładu kiedyś myśląc o projekcie zaczynałem z 3 warstwami, teraz żadko mi się zdarza - częściej "na dzień dobry" zaczynam od 5 warstw (IMG:http://forum.php.pl/style_emoticons/default/sad.gif) ).

Bardzo mi się spodobały artykuły Michała Gołębiowskiego oraz Simon-a Guest-a w tym temacie.


Więc proponuję, utworzyć nową dyskusję na temat tego kiedy zanika ta cieniutka linia pomiędzy dobrym, modularny i elastycznym projektem a "over engineering".

Pozdrawiam.

Ten post edytował nasty 30.01.2009, 05:08:22

[starach]

Przyłączam się do obu powyższych próśb o utworzenie tematów. W archiwum jest co prawda temat o debugowaniu skryptów, ale ma on 3 lata. Jak dla metodologi odpluskwiania to całe wieki. Chciałbym się dowiedzieć jak powinno się postępować przy wystąpieniu błędu, którego nie da się od razu zlokalizować. Jaka w takich przypadkach powinna być procedura postępowania. Z góry dziękuję.

Ten post edytował orglee 10.02.2009, 18:38:35

[Zigi]

Witam,
prosiłbym o utworzenie tematu o "Tworzeniu API do wykorzystania przez zewnetrzne serwisy".
Najbardziej chodzi o dyskusje o tym jak powinna wygladac komunikacja (jaki protokół wykorzystać). W jaki sposob obudowywac serwis dodatkowym api. Czy tworzyc calkowicie odrebne pliki z funkcjami, czy tez moze jak wplesc razem.

[bim2]

Także przyłączam się do tematu na temat debugowania skryptów php. (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

[athabus]

Jak już się przyłączamy to ja oddaje głos na API.
Będę robił właśnie coś podobnego i fajnie byłoby nie popełniać kardynalnych błędów.
Debugowanie też popieram ;-)

[S_Olewniczak]

Jak piszemy aplikację php? Czy używamy jakiegoś frameworka? Jakiego? Co się dla nas liczy przy pisaniu aplikacji? Szybkość ich tworzenia, czy szybkość działania samej aplikacji?

[phpion]

Również jestem za API. Jak PRO to PRO, a nie jakieś pierdy, które co drugi programista jest w stanie wykonać.

[cojack]

Ja jestem za tematem Routing - Routery, wg mnie dość ciekawy.

[bim2]

Ja jestem za tematem Routing - Routery, wg mnie dość ciekawy.

Ehh...
Temat: Routery i sposoby routingu

[batman]

Jak Pro, to Pro:
Windows Azure SDK for PHP Developers
i/lub
Toolkit for PHP with ADO.NET Data Services

[darko]

A ja z chęcią poczytałbym opinie na temat php + GUI + dostęp do bazy danych, a zwłaszcza: jak, czy koniecznie gtk2 i soap, czy nie lepiej jakiś inny niż php język programowania (php nie jest najlepszym rozwiązaniem dla aplikacji z własnym gui) oraz dodatkowo: czy temat php-gtk2 umrze/już umarł śmiercią naturalną?

[Nattfarinn]

A ja z chęcią poczytałbym opinie na temat php + GUI + dostęp do bazy danych, a zwłaszcza: jak, czy koniecznie gtk2 i soap, czy nie lepiej jakiś inny niż php język programowania (php nie jest najlepszym rozwiązaniem dla aplikacji z własnym gui) oraz dodatkowo: czy temat php-gtk2 umrze/już umarł śmiercią naturalną?

Na to pytanie może udzielić Ci odpowiedzi każda, średnio zorientowana w PHP osoba i nie wymądrzając się mogę powiedzieć, że nie podlega to żadnej dyskusji. Sztuka dla sztuki ma swoje granice, a z klocków lego można budować nawet łodzie podwodne - pytanie tylko po co (IMG:style_emoticons/default/winksmiley.jpg) .

Jak Pro, to Pro

Słuszna uwaga (IMG:style_emoticons/default/smile.gif) . Ja proponowałbym dyskusję na temat implementacji AOP (Aspect Oriented Programming) w PHP oraz jego wadach czy zaletach. Nie tak nowe i nie tak popularne zagadnienie, ale jednak to kolejny etap ewolucji programowania. (IMG:style_emoticons/default/smile.gif)

[Moli]

Może trochę mniej "pro" niż tematy wyżej wymienione, ale dyskusja na temat budowy newsletter (z prawdziwego zdarzenia, gdzie wiadomości wysyłane są do XX tysięcy osób) ?

[nospor]

z prawdziwego zdarzenia, gdzie wiadomości wysyłane są do XX tysięcy osób

temat juz byl omawiany w dziale PHP

[phpion]

Drugi raz intensywnie pracuję z Allegro API i stąd moja propozycja: może warto utworzyć osobny temat pod tym kątem?

[piotrooo89]

skoro mówimy już o API to możemy podyskutować o czymś od googla. wykresy, mapy, adsense do wyboru do koloru.

Ten post edytował piotrooo89 10.11.2009, 11:34:11

[Cysiaczek]

Tematy związane z API Google i Allegro są ciekawe, lecz wszystko zależy od tego o czym chcecie dyskutować. Jeśli o tym, jak zrobić jakąś konkretną rzecz, to to nie PRO, tylko jakiś samouczek. Też mile widziany, ale nie w tym dziale. Jeśli ktoś pokusi się o dyskusję o czymś bardziej ogólnym w tym zakresie, to ok - niech przedstawi propozycję tematu (IMG:style_emoticons/default/smile.gif)

Pozdrawiam

[Blame]

Chciałbym zaproponować temat, który byłby niejako rozwinięciem posta Zyx'a o "prawdziwym MVC". Konkretnie chodzi mi o ten post: http://forum.php.pl/index.php?s=&showt...st&p=709863
Z chęcią dowiedziałbym się coś więcej na ten temat. Interesuje mnie również dlaczego największe frameworki odstąpiły od tego wzorca.

[blooregard]

Popieram @Blame'a, gdyż właśnie Zyx otworzył mi dzisiaj oczka na prawdziwość implementacji MVC w apliakcjach internetowych i też chciałbym temat "pociągnąć" (bez skojarzeń proszę (IMG:style_emoticons/default/smile.gif) )