W dniu 2011-01-20 10:23, Piotr Siudak pisze:
> W dniu 20.01.2011 07:38, Peter May pisze:
>> W dniu 2011-01-20 00:14, Piotr Siudak pisze:
>>> W dniu 19.01.2011 14:35, Peter May pisze:
>>>> Można tak, ale to nie zdaje egzaminu, bo i tak muszę nieco pomieszać
>>>> PHP
>>>> i JavaScript.
>>>>
>>>
>>> Nie, nie musisz. Po prostu tak wolisz. Jak najbardziej mozna to zrobic w
>>> miare elegancko nie mieszajac dwóch róznych rodzajów kodu. Ty
>>> zdecydowaleś zrobic to inaczej - twoja sprawa. Nie rozumiem tylko czemu
>>> cie dziwi że autorzy narzedzi do programowania tez uwazaja takie
>>> podejście za raczej ekstrawaganckie.
>>
>> Podaj przykład
>
> widziałes kiedys jakis system szablonów? w analogiczny.
> W kodzie js w miejsce oczekiwanych zmiennych wstawiasz jakies
> __here_goes_my_variable_x__ a przy wyswietlaniu w to miejsce podmieniasz
> $data['x'].

Przy kodzie typu inline to proste. Wobec tego jak przekazujesz zmienne i
ich zawartość do pliku zewnętrznego JavaScript, który w kodzie html
załączam po prostu <script type="text/javascript" src="plik.js"></script> ?

>>>> Z resztą co to za argument "to se kup lepszy"?
>>>
>>> Żaden. To nie był argument tylko dobra rada.
>>
>> To nie jest żadne rozwiązanie problemu.
>
> pomogę ci to zrozumieć krok po kroku

Doskonale.

> problem: program działa wolno
> oczekiwany rezultat: program działa normalnie

Program _ma działać_ normalnie.

> propozycja rozwiazania problemu: kupić współczesny mu komputer

> czy propozycja rozwiazuje problem? tak, po zastosowaniu proponowanej
> propozycji występuje oczekiwany rezultat
>
> To *jest* rozwiązanie problemu.

To jest rozwiązanie problemu, ale niekoniecznie najbardziej efektywne.
Może lepiej sprawdzić inne rzeczy jeszcze jak ilość uruchamianych
programów w autostarcie, może pamięć da się zwiększyć, itd. Czasem
zmiana oprogramowania na _konkurencyjne_ też rozwiązuje problem bez
wymiany sprzętu.

> > Tak samo "zepsuło się" Zend
>> Studio, które legalnie nabyte w wersji 5.5 działało przyzwoicie. A
>> dalsze wersje to już tragicznie powolne narzędzie.
>
> jak jeszcze kilka lat popracujesz z komputerami to sytuacja taka że
> kolejne wersje oprogramowania maja wieksze wymagania dotyczace sprzetu
> przestanie cie zaskakiwać.

To mnie nie zaskakuje. Tyle, że nie muszę za każdym razem wymieniać
sprzętu, bo _jeden_ program mi nie działa.

>> Rozumiem, że w Twoim programowaniu nie ma czegoś takiego, jak
>> optymalizacja, a klienci korzystający z Twoich rozwiązań albo
>> zaakceptują to, co dostają, albo niech sobie wymienią sprzęt.
>
> szybkość działania aplikacji nie jest jakims świetym gralem.
> oprogramowanie powinno sie tworzyć majac w głowie cel by było ono *dobre*.

To raczej tylko jeden z parametrów.

> *jeżeli* wystepuje potrzeba przyspieszenia aplikacji mozna to zrobić na
> dwa sposoby. identyfikując wąskie gardła i poprawiajac gotowy kod w tych
> miejscach lub kupujec wiecej sprzetu. Często drugie rozwiazanie jest tańsze

To drugie rozwiązanie nie jest częściej tańsze. Koszt zakupu sprzętu,
jego konfiguracji, w tym oprogramowania i ustawień, plus czas przestoju,
itd. niekoniecznie musi być takie efektywne. Ok, jeden czy dwa komputery
może i by warto czasem wymienić, ale już przy np. 50 tak pochopnie po
prostu wymieniasz sprzęt? Ciekawe, który księgowy na to zezwoli ot, tak
sobie.

>> Niestety,
>> prezentuję inne podejście.
>
> współczuje

To nie jest potrzebne. Natomiast wypowiedzi merytoryczne i bez emocji na
pewno.

--
Peter