W dniu 20.01.2011 10:57, Peter May pisze:
> 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> ?

tak samo. dane wysyłam do kontrolera który wywołuje odpowiedni tryb widoku.

mozna też wszystkie dane generowane serverside zainicializować jako
zmienne w <script></script> a dopiero potem dołaczyć statyczny plik js
który z tych zmiennych skorzysta



>
>>>>> 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.

to zalezy jak mierzysz efektywność. Warto precyzyjnie mierzyć czas
stracony na poszukiwania rozwiazań, konfigurowanie starych rzęchów żeby
jednak mozna było na nich pracować i tak dalej.

Komputer na którym można sprawnie nie marnujac czasu pracować nawet na
programach działajacych u ciebie "jak wóz z węglem" kosztuje maksymalnie
1000 złotych. Nie wiem ile kosztuje klienta godzina twojej pracy ale
podejrzewam że taki zakup zwraca sie najdalej w ciagu tygodnia.


>> 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.

jasne, mozesz pogrzebac w autostarcie, poszukac jakiegos innego
oprogramowania, zainstalowac, nauczyc sie na tym pracować i tak dalej.
Na ile godzin wyceniasz te zabiegi? bo jak na wiecej niz czas w którym
jesteś w stanie zarobić 1000 złotych to chyba jednak nie warto

>>
>> 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.

sprecyzuje: oprogramowanie powinno realizować oczekiwania klienta.
Optymalne wykorzystanie sprzetu jest pirorytetem rzadko stawianym przez
klientów wysoko. To jest raczej taki gimlick którym podniecaja sie
programiści.

> Ok, jeden czy dwa komputery
> może i by warto czasem wymienić, ale już przy np. 50 tak pochopnie po
> prostu wymieniasz sprzęt?

co znaczy pochopnie? "nie mozemy pracować, tracimy pieniądze" to nie
jest byle argument z dupy...

> Ciekawe, który księgowy na to zezwoli ot, tak sobie.

nie "ot, tak sobie" tylko zwykle prosi o mniej lub bardziej szczegułowe
dane dotyczących tych traconych pieniędzy i porównuje sobie z kosztem
zakupu.



--
Piotr Siudak
s...@x...pl