JSP Servlets vs PHP

[szymkraw]

Dostalem zadanie przeksztalcic portal zbudowany w php. Kod jest szczerze mowiac niezbyt dobry i czytelny zadnych obiektow kod struktualny. Zaproponowalem JSP Servlets. Kodu bedzie wiecej ale wszystko ladnie rozdzielilem do odpowiednich klas, sa watki wszystko idzie w dobra strone jak narazie. Niedlugo bede przedstawial prototyp menadzerowi i potrzebuje malej pomocy.
Moglibyscie pomoc mi z argumentacja?

Jak narazie wymyslilem cos takiego:
1) Bardziej czytelny kod dzieki programowaniu obiektowemu
2) Prototyp nie dlawi sie tam gdzie sie dlawil w php
3) Mozliwosc latwiejszej rozbudowy serwisu
4) Mozliwosc uzycia GIT
5) Lepsze mozliwosci budowania statystyki dla serwisu.(Teraz ciezko zbierac mi dane z roznych logow i korelowanie danych

Prosze tez o opinie czemu nie isc w kierunku JSP Servlets. Jaka inna technologie moglbym wybrac?
Wszystkie opinie sa dla mnie rownie wazne i wartosciowe.
Dzieki

[lame2]

Brak klas jeszcze o niczym nie świadczy.
95% kodu PHP jaki piszę umieszczam w "global-scope"..
"Glue-code PHP" powinien siedzieć w global-scrope, bo tam można w biegu definiować klasy (np. observers).
Bez tego definicja klasy ląduje (z grubsza biorąc) w bliżej nieokreślonym miejscu/module/pluginie/helperze/pliku..
Szukanie błędów i ogólnie maintenance takiego kodu to dla mnie osobiście "pokój 101".
Cały mój kod PHP siedzi w jednym pliku: "api.php" (przy małym projekcie jakieś 4000 linii).
Argumentu githuba nie rozumiem. Chyba każdy projekt da się wrzucić na githuba.

Moim zdaniem powinieneś zacząć od zaprojektowania aplikacji, stosując na przykład podejście "Domain Driven Design".

[szymkraw]

w czym moze pomoc mi Glue-code PHP? Czy chodzi Ci o to: GluePHP - about
Jakie sa zalaty tego ze wszystko wrzucisz do jednego pliku api.php?
Zaciekawiles mnie podaj jakis przyklad wyjasnij jak Ty tego uzywasz ?
Jakies pros cons please

[lame2]

Definicja glue code:
→ Glue code

Zalety 1 pliku z całym glue-code/crud czy jak byś tego nie nazwał, są następujące:
- mniej przeskakiwania między plikami w edytorze tekstowym (oszczędzasz czas)
- możliwość zredukowania widocznej części kodu przez użycie "code folding", dięku temu możesz na jednej dwóch stronach miec dosep do piewszego poziomu logiki całej pierdolonej aplikacji

Szkielet pliku api.php wygląda tak:

<?php

error_reporting(0);
@ini_set('display_errors', 0);

// require_once 'config.php';
// @package: https://docs.google.com/uc?id=0B7KFLJQ_HETDM1lyc2FKb2FiQUE&export=download
require_once 'database/DB.php';
if ( ! $db ){
    if ( ! $dbconfig ){
        $dbconfig = array(
            'hostname' => 'localhost',
            'username' => 'root',
            'password' => '',
            'database' => '',
            'dbprefix' => '',
        );
    }
    $dbconfig = array_merge(array(
        'dbdriver' => 'mysql',
        'pconnect' => false,
        'db_debug' => true,
        'cache_on' => false,
        'char_set' => 'utf8',
        'dbcollat' => 'utf8_general_ci',
    ), $dbconfig);
    try {
        $db = DB($dbconfig);    
    }
    catch ( Exception $e ){
        die($e->getMessage());
    }
}
if ( ! function_exists('action')){
    function action($params){
        $old_request = $_REQUEST;
        foreach ($params as $key => $val){
            $_REQUEST[$key] = $val;
        }
        ob_start();
        include 'api.php';
        $content = ob_get_contents();
        ob_end_clean();
        $json = json_decode($content, true);
        if ( JSON_ERROR_NONE === json_last_error()){
            $content = $json;
        }
        $_REQUEST = $old_request;
        return $content;
    }
}
if ( $_COOKIE['sess_id'] ){
    $result = $db
        ->where('id', $_COOKIE['sess_id'])
        ->limit(1)
        ->get('session')
        ->row_array();
    if ( $result ){
        $user = $result['user_id'];
    }
    else {
        $user = null;
    }
}
else {
    $user = null;
}
switch ($_REQUEST['action']){
    // ADMIN
    // AUTH
    // CRON
    // PUBLIC
    // TESTS
    case '':
        break;
    default:
        $result = array(
            'status' => 'error',
            'message' => 'No action name in request',
        );
        break;
}
if ( getenv('HTTP_ORIGIN')){
  header('Access-Control-Allow-Origin: '.$_SERVER['HTTP_ORIGIN']);
    header('Access-Control-Allow-Methods: POST, GET, OPTIONS');
    header('Access-Control-Max-Age: 1000');
    // header('Access-Control-Allow-Headers: Content-Type');
    header('Access-Control-Allow-Headers: x-requested-with ');
}
if ( ! $_no_output ){
    if ( $_REQUEST['callback'] ){
        header('Content-type: application/javascript');
        // echo 'callback(\''.json_encode($result).'\');';
        echo '/**/ callback(\''.json_encode($result).'\');';
    }
    else {
        header('Content-type: application/json');
        echo json_encode($result);
    }
} $_REQUEST['callback'] ){
        header('Content-type: application/javascript');
        // echo 'callback(\''.json_encode($result).'\');';
        echo '/**/ callback(\''.json_encode($result).'\');';
    }
    else {
        header('Content-type: application/json');
        echo json_encode($result);
    }
}

Do tego mam oczywiście masę dodtaków, jedna z najważniejszych to rekurencja:

<?php

$res = action(array(
    'action' => '',
    // '' => $,
));

Ale wracając do dyskusji JSP vs PHP for webapp backend.
Każdy ninja wie, że PHP nadaje się do tego lepiej.
Dziękuję

[szymkraw]

Ja mam ponad 80 plikow php z czego okolo 10 ma cokolwiek do roboty z wyswietleniem storny uzytkownikowi. Reszta z nich wykonuje oparacje na plikach xml ktore sa generowane po stworzeniu modelu UML. Oprogramowanie ktorego uzywamy robi walidacje tych modeli przy uzyciu dtd i schematron . Nasz tool uzywany jest do backward validation jak i ponownie sprawdza xml uzywajac dtd i schematron. Pozniej kazde entity i property z xml jest sprawdzane jednym z tych pozostalych 70 skryptow ktore maja srednio 1000 lini kodu. Kazdy z tych skryptow ma okolo 20 roznych funkcji ktore odpalane sa jedynie jesli pewne specyficzne warunki zostaly spelnione. Dalej uwazasz ze powinnienem wrzucic wszystko do jednego pliku?
Pozatym kod ma problem z walidacja modeli powyzej 5kb a takie sie zdazaja tez!!
Porownujac czas wykonywania kodu php i prototypu mojego wyniki sa zadawalajace ponad 20% zysku w czasie i rosnie proporcjonalnie z wielkoscia modeli.
Uwazasz ze multi-threading w php jest tak samo przejrzysty jak w Javie?
W mojej pierdolonej aplikacji trudno powiedziec ze ma tylko kilka poziomow logiki lol.
Twoj kod ma 4tys lini kodu to dosc latwo ogarnac. Kod php dziala ale coraz gorzej bo coraz wiecej modeli jest coraz wiekszych a znalesc przyczyne gdzie co sie dusi jest bardzo trudne.

[lame2]

Pytasz w zasadzie czy opłaca się przepisywać z php na php.
To zależy od jakości kodu, podeślij package, a ja w tym czasie napiszę ogólnie...

Musisz porównac zyski i straty,
straty to:
- czas poświęcony na przepisywanie
- trudne testowanie
zyski to:
- potencjalnie najszybszy maintaince
- przystępność dla modyfikacji (nie zaburzasz struktury bibliotek, bo wszystko jest "glue", a glue ma swój (mój :]) szczegółowo zdefiniowany styl )

W ogóle, wybór technologii z niektórych punktów widzenia może być nieznaczącym sporem.
Bo przecież mając doskonały projekt nawet w PDF (pełno dobrych UML'i) to co za różnica w czym to napiszesz?
Różnicy nie ma, liczy się tylko profesjonalizm developera, bo każdy developer ma w swojej technologii opanowane pisanie stabilnego softu.
Z drugiej strony często jest tak, że żeby dojść do "kodu dobrej jakości" (cokolwiek to znaczy) musisz najpierw napisać prototyp,
a potem przepisać go według standardów.
100% Mojego kodu kończy się na etapie prototypowania, a mimo to wszystko śmiga i wypluwa dolary

[szymkraw]

Nie zrozumielismy sie
UMLe a raczej wygenerowane XMLe user wysyla to tego toola.
Tool sprawdza czy nowsza wersja XMLa(czyli nowa wersja UML) jest backward compatible z starsza wersja. Pewne rzeczy sa sprawdzane juz w czasie pisania kodu i generowania XML. Ale pewne rzeczy nie mozna sprawdzic dlatego stworzona byla ta strona. Problem w tym ze nowe XMLe coraz czesciej przekraczaja 5kb (100tys lini 50tys roznych tagow) i wlasnie kod PHP nie daje rady. Zlozonosc tego kodu powoduje ze jest on bardzo trudny w debug'owaniu. Przepisanie PHP na JSP i Servlets dalo mi dobre wyniki. Problem jest w przekonaniu menadzera ktory musi przekonac pozniej stockholders ze to bedzie lepsze rozwiazanie pozniej trzeba przekonac rowniez ludzi od serverow zeby postawili serwer Tomcat gdzie kolwiek uwazaja za stosowne.

Ja potrzebuje dobre za i przeciw dlaczego JSP albo czy zostac przy PHP.

[lame2]

Ja zrozumiałem bardzo dobrze i uważam że pytasz tylko o to czy warto przepisać php na php tuzież php na jsp. Bez źródeł nie da się konkretnie odpowiedzieć.

Wszystko da się napisać, nawet generowanie 1GB XMLi w PHP używając 1kb pamięci.
Jeśli nie przewidziałeś tego na początku, to popełniłeś błąd projektowy, a skoro tak to być może w ogóle jesteś słaby

[szymkraw]

Parsowanie juz Ci sie nie uda

No to pros cons przepisania php na php i php na jsp?
Nie odpowiedziales na pytanie czy uwazasz ze multi-threading jest tak samo latwy jak w javie?
Bo bez kilku watkow to bedzie zajmowalo wiecznosc.
Zrodel nie moge Ci udostepnic niestety NDA

[lame2]

Po co bawić się w obsługę multi-threating na poziomie aplikacji, skoro przy ruchu 3 użytkowników lub więcej to przestaje się opłacać i lepiej zostawić to odpowiedniej warstwie serwera www?