Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.lang.php > #15879 > unrolled thread

PHPStorm - jak tworzyć wzorce HTML?

Back to article view | Back to pl.comp.lang.php

Contents

  PHPStorm - jak tworzyć wzorce HTML? Marek S <precz@spamowi.com> - 2018-12-16 01:13 +0100
    Re: PHPStorm - jak tworzyć wzorce HTML? Borys Pogoreło <borys@pl.edu.leszno> - 2018-12-16 12:30 +0100
      Re: PHPStorm - jak tworzyć wzorce HTML? Marek S <precz@spamowi.com> - 2018-12-16 16:33 +0100
        Re: PHPStorm - jak tworzyć wzorce HTML? Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-12-16 17:02 +0100
          Re: PHPStorm - jak tworzyć wzorce HTML? Marek S <precz@spamowi.com> - 2018-12-16 17:27 +0100
            Re: PHPStorm - jak tworzyć wzorce HTML? Borys Pogoreło <borys@pl.edu.leszno> - 2018-12-16 17:45 +0100
              Re: PHPStorm - jak tworzyć wzorce HTML? Marek S <precz@spamowi.com> - 2018-12-16 19:10 +0100
                Re: PHPStorm - jak tworzyć wzorce HTML? Borys Pogoreło <borys@pl.edu.leszno> - 2018-12-16 19:21 +0100
                  Re: PHPStorm - jak tworzyć wzorce HTML? Marek S <precz@spamowi.com> - 2018-12-16 20:25 +0100
                    Re: PHPStorm - jak tworzyć wzorce HTML? Borys Pogoreło <borys@pl.edu.leszno> - 2018-12-16 22:19 +0100
                      Re: PHPStorm - jak tworzyć wzorce HTML? Marek S <precz@spamowi.com> - 2018-12-17 22:11 +0100
                        Re: PHPStorm - jak tworzyć wzorce HTML? Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-12-18 08:04 +0100
                          Re: PHPStorm - jak tworzyć wzorce HTML? Marek S <precz@spamowi.com> - 2018-12-18 21:27 +0100
                    Re: PHPStorm - jak tworzyć wzorce HTML? Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-12-17 20:36 +0100
                      Re: PHPStorm - jak tworzyć wzorce HTML? Marek S <precz@spamowi.com> - 2018-12-17 22:12 +0100
                        Re: PHPStorm - jak tworzyć wzorce HTML? Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-12-18 07:54 +0100
                          Re: PHPStorm - jak tworzyć wzorce HTML? Marek S <precz@spamowi.com> - 2018-12-18 21:32 +0100
                  Re: PHPStorm - jak tworzyć wzorce HTML? Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-12-17 20:35 +0100
        Re: PHPStorm - jak tworzyć wzorce HTML? Kviat - 2018-12-16 17:03 +0100
          Re: PHPStorm - jak tworzyć wzorce HTML? Marek S <precz@spamowi.com> - 2018-12-16 17:25 +0100
            Re: PHPStorm - jak tworzyć wzorce HTML? Borys Pogoreło <borys@pl.edu.leszno> - 2018-12-16 17:43 +0100
              Re: PHPStorm - jak tworzyć wzorce HTML? Marek S <precz@spamowi.com> - 2018-12-16 19:29 +0100
                Re: PHPStorm - jak tworzyć wzorce HTML? Borys Pogoreło <borys@pl.edu.leszno> - 2018-12-16 19:53 +0100
                  Re: PHPStorm - jak tworzyć wzorce HTML? Marek S <precz@spamowi.com> - 2018-12-16 20:53 +0100
                    Re: PHPStorm - jak tworzyć wzorce HTML? Borys Pogoreło <borys@pl.edu.leszno> - 2018-12-16 22:09 +0100
                      Re: PHPStorm - jak tworzyć wzorce HTML? Marek S <precz@spamowi.com> - 2018-12-17 23:05 +0100
                        Re: PHPStorm - jak tworzyć wzorce HTML? Borys Pogoreło <borys@pl.edu.leszno> - 2018-12-26 18:02 +0100
                          Re: PHPStorm - jak tworzyć wzorce HTML? Marek S <precz@spamowi.com> - 2018-12-26 21:14 +0100
                            Re: PHPStorm - jak tworzyć wzorce HTML? Borys Pogoreło <borys@pl.edu.leszno> - 2018-12-26 23:32 +0100
                              Re: PHPStorm - jak tworzyć wzorce HTML? Marek S <precz@spamowi.com> - 2018-12-28 23:20 +0100
                                Re: PHPStorm - jak tworzyć wzorce HTML? Borys Pogoreło <borys@pl.edu.leszno> - 2018-12-29 01:33 +0100
                                  Re: PHPStorm - jak tworzyć wzorce HTML? Marek S <precz@spamowi.com> - 2018-12-29 21:16 +0100
            Re: PHPStorm - jak tworzyć wzorce HTML? Kviat - 2018-12-16 18:13 +0100
              Re: PHPStorm - jak tworzyć wzorce HTML? Marek S <precz@spamowi.com> - 2018-12-16 20:11 +0100
                Re: PHPStorm - jak tworzyć wzorce HTML? Borys Pogoreło <borys@pl.edu.leszno> - 2018-12-16 22:17 +0100
                  Re: PHPStorm - jak tworzyć wzorce HTML? Marek S <precz@spamowi.com> - 2018-12-17 23:20 +0100
                    Re: PHPStorm - jak tworzyć wzorce HTML? Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-12-18 07:59 +0100
                      Re: PHPStorm - jak tworzyć wzorce HTML? Marek S <precz@spamowi.com> - 2018-12-18 21:36 +0100
                        Re: PHPStorm - jak tworzyć wzorce HTML? Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-12-18 22:19 +0100
                          Re: PHPStorm - jak tworzyć wzorce HTML? Marek S <precz@spamowi.com> - 2018-12-22 20:02 +0100
                            Re: PHPStorm - jak tworzyć wzorce HTML? Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-12-22 20:51 +0100
                              Re: PHPStorm - jak tworzyć wzorce HTML? Marek S <precz@spamowi.com> - 2018-12-23 15:14 +0100
                                Re: PHPStorm - jak tworzyć wzorce HTML? Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-12-27 13:06 +0100
                Re: PHPStorm - jak tworzyć wzorce HTML? Kviat - 2018-12-16 23:12 +0100
                  Re: PHPStorm - jak tworzyć wzorce HTML? Marek S <precz@spamowi.com> - 2018-12-17 23:55 +0100
                    Re: PHPStorm - jak tworzyć wzorce HTML? Kviat - 2018-12-18 10:24 +0100
                      Re: PHPStorm - jak tworzyć wzorce HTML? Marek S <precz@spamowi.com> - 2018-12-18 21:52 +0100
                        Re: PHPStorm - jak tworzyć wzorce HTML? Kviat - 2018-12-19 02:45 +0100
                          Re: PHPStorm - jak tworzyć wzorce HTML? Marek S <precz@spamowi.com> - 2018-12-22 20:48 +0100
                            Re: PHPStorm - jak tworzyć wzorce HTML? Borys Pogoreło <borys@pl.edu.leszno> - 2018-12-26 17:43 +0100
                              Re: PHPStorm - jak tworzyć wzorce HTML? Marek S <precz@spamowi.com> - 2018-12-26 21:20 +0100

Page 3 of 3 — ← Prev page 1 2 [3]

#15942

On 2018-12-22, Marek S <precz@spamowi.com> wrote:

>> Ty się nabijasz, a przypadkiem nabijasz się personalnie ze mnie,
>
> Nie nabijam się z Ciebie lecz z adekwatności argumentu jaki został-
> wytoczony do tematyki o jakiej jest mowa.  A mowa jest o tym, że ponoć-
> korzystanie z możliwości hurtowego tworzenia i aktualizowania-
> pełnowartościowych plików HTML w np. widokach jakiegoś frameworku jest-
> niestosowne i trąci latami 90tymi.

Przypomnę, że w tym podwkątku pisaliśmy o możliwościach przeglądarek
w zakresie tzw. zwiększania dostępności, na co zgryźliwie zapytałeś,-
czy ja o takie rzeczy dbam w swoich projektach. Sugerowałeś wręcz,-
że mało kto tego używa, więc Cię postanowiłem uświadomić, że jednak-
nie - nie jest takich osób mało.

>> jako z osoby niepełnosprawnej z silną dysfunkcją wzroku, która tego typu
>> narzędzia używa w praktyce by móc cokolwiek przeczytać.
>
> A teraz to grubo pojechałeś. Nie będę takich tekstów nawet komentował.-
> Doradzę tylko, że skoro nie możesz przeczytać, co jest napisane, to na-
> podstawie fragmentów wyrwanych z kontekstu, które jednak udało się-
> przeczytać, nie próbuj oczerniać innych osób imputując im obraźliwe-
> przekazy.

Jakoś mam wrażenie, że lepiej ogarniam kontekst od Ciebie, więc to raczej
Ty starasz się mnie oczernić unikając argumentacji tylko dlatego że dowiedziałeś
się o mojej wadzie. Brawo! To jeszcze Cię uświadomię, że wada nie wpływa
na moją pamięć, czy na umiejętność kojarzenia faktu ale tylko i wyłącznie
na pole widzenia i fakt nierozróżniania małych liter (co można skorygować). 
Więc to że używam narzędzi powiększających tekst, czy poprawiających kontrast, 
nie oznacza że czytam-fragmenty wyrwane z kontekstu i wmawianie mi czegoś 
takiego by uniknąć odpowiedzi, czy zaakceptowania faktu jest bardzo słabe.

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

[toc] | [prev] | [next] | [standalone]

#15947

W dniu 2018-12-22 o 20:51, Wojciech Bancer pisze:

>> Nie nabijam się z Ciebie lecz z adekwatności argumentu jaki został-
>> wytoczony do tematyki o jakiej jest mowa.  A mowa jest o tym, że ponoć-
>> korzystanie z możliwości hurtowego tworzenia i aktualizowania-
>> pełnowartościowych plików HTML w np. widokach jakiegoś frameworku jest-
>> niestosowne i trąci latami 90tymi.
> 
> Przypomnę, że w tym podwkątku pisaliśmy o możliwościach przeglądarek
> w zakresie tzw. zwiększania dostępności, na co zgryźliwie zapytałeś,-
> czy ja o takie rzeczy dbam w swoich projektach. Sugerowałeś wręcz,-
> że mało kto tego używa, więc Cię postanowiłem uświadomić, że jednak-
> nie - nie jest takich osób mało.

Inaczej: to Ty sobie o tym pomyślałeś, a nie "my" piszemy na ten temat.

A piszemy w kontekście tego czy kolumna o 100px nie pomieści 
powiększonego tekstu - więc w domyśle, projektowanie wysiwyg jest 
pozbawione sensu. Argument z czapy. Ma się to jak pięść do nosa. Wysiwyg 
to nie ogranicza się przecież do stosowania pikseli jako jednostek. 
Szukanie więc na siłę wydumanego argumentu by udupić stosowanie wysiwyg 
jest podejściem, które wykracza poza rozsądny dialog.

> 
> Jakoś mam wrażenie, że lepiej ogarniam kontekst od Ciebie,

Interesujące - ogarniasz lepiej kontekst od autora wątku... Wiesz zatem 
lepiej niż ja, co miałem na myśli.

> więc to raczej
> Ty starasz się mnie oczernić unikając argumentacji tylko dlatego że dowiedziałeś
> się o mojej wadzie. Brawo! To jeszcze Cię uświadomię, że wada nie wpływa
> na moją pamięć, czy na umiejętność kojarzenia faktu ale tylko i wyłącznie
> na pole widzenia i fakt nierozróżniania małych liter (co można skorygować).
> Więc to że używam narzędzi powiększających tekst, czy poprawiających kontrast,
> nie oznacza że czytam-fragmenty wyrwane z kontekstu i wmawianie mi czegoś
> takiego by uniknąć odpowiedzi, czy zaakceptowania faktu jest bardzo słabe.

A jednak znów to czynisz. Powyżej tłumaczę, co komentuję.

A wkurzyło mnie to, że wykorzystałeś swoją martyrologię do tego by 
szmatę ze mnie zrobić wciskając uważając, że nabijam się z osób 
niepełnosprawnych. Dyskusję czysto techniczną naginasz w taki sposób by 
personalne, wyssane z palca przytyki zacząć uprawiać. Chore!

-- 
Pozdrawiam,
Marek

[toc] | [prev] | [next] | [standalone]

#15972

On 2018-12-23, Marek S <precz@spamowi.com> wrote:

[...]

>> że mało kto tego używa, więc Cię postanowiłem uświadomić, że jednak-
>> nie - nie jest takich osób mało.
>
> Inaczej: to Ty sobie o tym pomyślałeś, a nie "my" piszemy na ten temat.

Cytat od którego się zacząłm podwątek (Borysa):
----
Wybacz za dosadność, ale to jest wymaganie totalnie od czapy. Co w
sytuacji, gdy użytkownik ma powiększony sam tekst? Co jeśli używa innego
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
fontu? I czemu kolumna z imieniem ma 100px, a nie proporcjonalny udział w
^^^^^^
całości?
---

na co się dalej oburzyłeś, że to mało realne.
Więc podałem realne i konkretne przykłady.
Skończ wymyślać i przyjmij do wiadomości, że ludzie to robią.

[... ciach tłumaczenia nie na temat ...]

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

[toc] | [prev] | [next] | [standalone]

#15913

W dniu 2018-12-16 o 20:11, Marek S pisze:
> W dniu 2018-12-16 o 18:13, Kviat pisze:
> 
>>
>> Jest widoczny, bo zamiast ręcznie nanosić zmiany w 50 plikach, ten DW 
>> zrobił to za Ciebie.
> 
> Dokładnie tak! O tym właśnie piszę. Zaznaczyłem moim komentarzem to, że 
> to żadna magia lecz czysta funkcjonalność.
> 
>> I uważasz, że to jest właściwa praktyka?
> 
> Hmmm... raczej bardzo wygodne narzędzie do zastosowań w pewnych 
> sytuacjach. Np. bardzo cenię sobie możliwość podglądu widoków w MVC w 
> wersji live.
(...)

>> Czyli jak ktoś nie ma/nie używa DW, to powinien ręcznie zmiany w 
>> 50/100/1000 plikach nanieść, bo tak to powinno się robić?
>> Nie wydaje mi się.
> 
> Nie o tym mowa. Próbuję jedynie ten mechanizm jakoś przenieść na realia 
> PHPStorma - jeśli się da bo lubię widzieć co robię.
> 
>>
>> Ja widzę zasadniczą oszczędność, gdy nanoszę zmianę w jednym pliku, 
>> zamiast w 1000 plikach podstron.
>> Nawet sobie tego nie wyobrażam, żeby tak sobie pracę "organizować"...
> 
> No widzisz. Bo to kwestia posiadania odpowiednich narzędzi i zdobycia 
> doświadczenia na nich.

Szczerze? Nawet gdybym miał takie narzędzie, to nie wpadłbym na to, żeby 
tak robić.

>> Nie przekonałeś mnie :) Jak to nie będę miał bladego pojęcia?
>> To chyba jakiś cud, że powstają strony o tysiącach podstron, skoro 
>> twórcy nie mają pojęcia jak będzie wyglądała kolumna newsów...
> 
> Powstają metodą prób i błędów. Skąd wiesz czy np. najdłuższe 
> dopuszczalne imię zmieści się w komórce tabeli o sztywno ustawionej 
> szerokości 100px? A może będzie to 150px? Wtedy poprawiasz CSS, 
> przesyłasz na serwer (jeśli lokalnie nie pracujesz), odświeżasz okno 
> przeglądarki (jeśli to się da zrobić by widoku nie utracić), 
> stwierdzasz, że jeszcze więcej px potrzeba, więc znów powtarzasz 
> procedurę i tak do skutku aż trafisz.

A Ty skąd to wiesz? Jak stwierdzasz, że jeszcze więcej px potrzeba? 
Nanosisz zmianę na 150px i przeglądasz 30 tysięcy plików html z 
produktami żeby wyłapać, że w jednym nazwa produktu się nie zmieściła?

> Ja tymczasem preferuję przeciągnąć krawędź kolumny i na tym poprzestać. 

Ale żeby sprawdzić, czy to przeciągnięcie wystarczyło, to nadal musisz 
przejrzeć w przeglądarce 30 tys plików.

Swoją drogą, takie np. opisy produktów też wrzucasz ręcznie do tych 
plików html? A jak każdy produkt jest inny i ma inny 
opis/charakterystykę itd., to robisz to 30 tys. razy w 30 tys plików?

Albo ja nadal czegoś nie rozumiem.

> Mało tego, jeśli chodziłoby tylko o jedną wartość CSS, to pal sześć. Ale 
> czasem chodzi o znacznie więcej: np. zmienić paddingi by ładniej 
> wyglądało. Zmienić odstępy między wierszami itd. Coś tam dodać. Parę 
> kliknięć i masz. W minutę całkiem złożone poprawki do CSS/HTML 
> naniesiesz.

Wystarczy zmiana w pliku css. Na co Ci propagacja tych zmian do 
pozostałych plików html? Osadzasz css w każdym pliku zamiast linkować do 
jednego, wspólnego pliku z cssem?

A jak chcesz zmienić coś/treść w stopce? To zamiast mieć jeden 
plik-szablon ze stopką, to nanosisz zmianę w DW, włączasz ten update 
(czy jak to tam się nazywa) i w każdym z 30 tys plików html z produktami 
ten DW  nanosi zmianę automagicznie (automatycznie, skoro tak wolisz). A 
potem pchasz te 30 tys. zmienionych html-ów na docelowy serwer?

> A w metodzie prób i błędów kopiesz się z koniem dochodząc do 
> tego samego rezultatu po 30 odświeżeniach,

Nie mieszajmy dwóch rzeczy. Teraz próbujesz wykazać większą wygodę pracy 
w edytorze wysiwyg, gdzie podgląd masz w tym narzędziu, zamiast podglądu 
w przeglądarce (albo w kilku różnych przeglądarkach równocześnie na 
sąsiednim monitorze... ).
No i ok. Co kto lubi.

Odświeżanie można zautomatyzować.
Np. 
https://chrome.google.com/webstore/detail/easy-auto-refresh/aabcgdmkeabbnleenpncegpcngjpnjkc?hl=pl
Odpalasz na drugim monitorze...

> czyszczeniach cache 
> przeglądarki

Możesz wyłączyć skoro Ci przeszkadza.

> i frameworka.

Nie możesz wyłączyć?

> W/g mnie do bani jest praca na poziomie 
> kodera dla uzyskania efektów estetycznych.

Ale co to ma wspólnego z tym, że szukasz funkcjonalności w narzędziu, 
które umożliwi Ci te zmiany propagować na 30 tys plików html?
Przecież frontendowiec może sobie te zmiany zobaczyć mając jeden 
plik-szablon z przykładowymi danymi produktu "lorem ipsum"...
A czy zobaczy je w przeglądarce czy w programie wysiwyg, to przecież nie 
ma znaczenia.

>> Ośmielam się nie zgodzić.
>> Wręcz przeciwnie, to co Ty proponujesz nie jest dobrą praktyką.
>> Jak ktoś przejmie Twój projekt, to co? Jest skazany na nanoszenie 
>> najdrobniejszej zmiany w 50 plikach? I tak za każdą zmianą? Jest 
>> skazany na kupno DW?
> 
> Owszem, to też racja. Ale tego nie unikniesz.

Jak nie, jak tak? :)
Zmieniam treść stopki w jednym pliku i niezależnie jak dużo witryna ma 
podstron, to ta zmiana widoczna jest na wszystkich.
Magia?

> W poprzedniej firmie tak 
> miałem. Projekt powstał w PHPStorm. W firmie praca była na NetBeansach. 
> No i okazywało się, że np. foldowanie kodu było akceptowane ze składni 
> PHPStorm ale nierzadko dziwnie działało (zwijało czasem część kodu). 
> Jakiekolwiek poprawki wiązały się z koniecznością korekty tych miejsc bo 
> inaczej kod stawał się kompletnie nieczytelny.

Przepraszam, ale nie widzę związku z tematem...

> Skutek był taki, że podczas przebudowy projektu przez programistów 
> tysiące plików musiały być poprawiane bo... poprzednicy używali PHPStorm.

Nadal nie widzę związku z funkcjonalnością propagowania zmian na 
pierdyliard plików html.

>> Każdy rzeźbi jak lubi :)
>> Ja się przestraszyłem na samą myśl, żeby tak zrobić jakąś większą stronę.
>> Np. jakiś sklep z 30 tysiącami produktów. 30 tysięcy podstron?
>> No bez jaj :)
> 
> Heee... ciekawe, co piszesz. Miałem chyba ze 3 duże realizacje. W tym 
> sklep z konfiguratorem, z wyszukiwarką o dynamicznie zmieniających się 
> kryteriach itp. Produktów było ok 30-40 tys.

I faktycznie miałeś dla każdego produktu osobny plik html?

> z 3 kategorii (każda z nich 
> określała inny zestaw cech produktu), a które to wiązały się między 
> sobą. W tle API gadające z hurtowniami itd. Wszystko w DW. Szablonów 
> włącznie z podszablonami było może kilka sztuk. Widoków z tego 
> kilkadziesiąt. I konkretne zadanie - dodać statyczny przycisk w 
> (statycznej) stopce wszystkich stron. Zaglądam więc po roku (bo już nie 
> pamiętałem konstrukcji przedsięwzięcia) na stronę, "pokaż źródło", 
> odczytuję nazwę użytego szablonu, otwieram ten szablon, dodaję powyższy 
> guzik, wydaję polecenie "update" i w ciągu paru sekund poprawka 
> naniesiona.

I ten kod z przyciskiem dodał się do 40 tysięcy podstron z produktami?
Gdzie tu sens?

> Dokładnie tak samo jakbym używał SSI lub podobnych technik. 
> A korzyść taka iż każdy jeden widok otrzymałem jako pełnowartościowy 
> dokument HTML,

To ma być korzyść? 40 tys. osobnych plików html. Dla każdego produktu 
osobny?
Chyba inaczej rozumiem słowo korzyść, albo nadal nie rozumiem o czym 
piszesz. Po każdej duperelkowatej zmianie w stopce pchać na serwer 40 
tys plików... No nie ogarniam :)

Pozdrawiam
Piotr

[toc] | [prev] | [next] | [standalone]

#15922

W dniu 2018-12-16 o 23:12, Kviat pisze:

> 
> Szczerze? Nawet gdybym miał takie narzędzie, to nie wpadłbym na to, żeby 
> tak robić.
Nie dziwię się. To kwestia dostosowania sposobu myślenia do środowiska 
IDE w jakim się pracuje. Ja mam problem w drugą stronę. Trudno mi 
rezygnować z wysiwyg przesiadając się na PHPStorm bo

> A Ty skąd to wiesz? Jak stwierdzasz, że jeszcze więcej px potrzeba? 
> Nanosisz zmianę na 150px i przeglądasz 30 tysięcy plików html z 
> produktami żeby wyłapać, że w jednym nazwa produktu się nie zmieściła?

Bo ustalam jakieś założenia i pod nie tworzę projekt. Jeśli jakiś 
przypadek wykroczy poza te założenia, to wtedy trwają konsultacje co z 
tym zrobić: poprawić wpis, zmienić szerokość, dać dynamiczną szerokość, 
może wiele wierszy? Wszystko zależy od wypracowanych założeń. Czasem nie 
ja je ustalam lecz otrzymuję gotowe wytyczne.

>> Ja tymczasem preferuję przeciągnąć krawędź kolumny i na tym poprzestać. 
> 
> Ale żeby sprawdzić, czy to przeciągnięcie wystarczyło, to nadal musisz 
> przejrzeć w przeglądarce 30 tys plików.

Nie - tylko jeden szablon, na których te pliki bazują.

> Swoją drogą, takie np. opisy produktów też wrzucasz ręcznie do tych 
> plików html? A jak każdy produkt jest inny i ma inny 
> opis/charakterystykę itd., to robisz to 30 tys. razy w 30 tys plików?

Nie - jeden raz.

> Albo ja nadal czegoś nie rozumiem.

Tak, zauważyłem. Wyjaśniam. Te 30.000 produktów zwykle korzysta z 1 lub 
kilku szablonów. Szablon to plik HTML z odpowiednimi specjalnymi tagami, 
które określają nazwy sekcji, oznaczają sekcje podlegające edycji i te 
nie podlegające. Z tego powstaje plik HTML będący z kolei szablonem (w 
sensie frameworka tym razem) dla 10 tys produktów a inny dla 
pozostałych. Nie ma zatem potrzeby tworzenia 30000 plików lecz w 
praktyce jest ich kilka. Wszystkie one mogą mieć wspólne sekcje jak 
linki do CSS/JS. Wtedy modyfikując tą sekcję w jednym pliku szablonu, 
zmieniamy wszystkie zależne pliki HTML.

To nie ja wymyśliłem. Jeśli chcesz, to zainstaluj triala DW i zobacz jak 
działają template'y i regiony. Zobacz jak łatwo je modyfikować nawet 
jeśli jakiś region posiada powstawiane obce znaczniki przynależące do 
jakiegoś frameworka. Np. w blade stosujesz @foreach to modyfikacja 
tabeli (dostawienie kolumny np) jaką generuje, nie spowoduje zniszczenia 
elementów blade. Działa to naprawdę dobrze.

> 
>> Mało tego, jeśli chodziłoby tylko o jedną wartość CSS, to pal sześć. 
>> Ale czasem chodzi o znacznie więcej: np. zmienić paddingi by ładniej 
>> wyglądało. Zmienić odstępy między wierszami itd. Coś tam dodać. Parę 
>> kliknięć i masz. W minutę całkiem złożone poprawki do CSS/HTML 
>> naniesiesz.
> 
> Wystarczy zmiana w pliku css. Na co Ci propagacja tych zmian do 
> pozostałych plików html? Osadzasz css w każdym pliku zamiast linkować do 
> jednego, wspólnego pliku z cssem?

O tym właśnie mówię. Zmieniasz CSS losowo tak długo aż trafisz zamiast 
trafić przy pierwszym posunięciu.

Widzisz - dlatego w firmach zatrudnia się współpracujących webdesignerów 
z programistami. Jedni drugich nie potrafią zrozumieć. :-D

> A jak chcesz zmienić coś/treść w stopce? To zamiast mieć jeden 
> plik-szablon ze stopką, to nanosisz zmianę w DW, włączasz ten update 
> (czy jak to tam się nazywa) i w każdym z 30 tys plików html z produktami 
> ten DW  nanosi zmianę automagicznie (automatycznie, skoro tak wolisz). A 
> potem pchasz te 30 tys. zmienionych html-ów na docelowy serwer?

Tak. Oczywiście nie w takiej ilości. Duże projekty prowadzone tą metodą 
miewały po kilkadziesiąt plików. Ale mniejsza o to. Zwróć uwagę na inny 
aspekt. Masz frameworka, gdzie dzielisz jeden plik HTML na mnóstwo 
małych viewsów itp. Plików takich masz powiedzmy 100. Każdy posiekany, 
co daje sporo plików. Teraz webdesigner stwierdza, że zamiast jakiegoś 
DIVa dajemy 4. Każdy z tych view musi być zmieniony. Robisz to na 
piechotę. Tydzień roboty z korektą pomyłek zamiast 1 kliknięcie.

Coś za coś.

> Nie mieszajmy dwóch rzeczy. Teraz próbujesz wykazać większą wygodę pracy 
> w edytorze wysiwyg, gdzie podgląd masz w tym narzędziu, zamiast podglądu 
> w przeglądarce (albo w kilku różnych przeglądarkach równocześnie na 
> sąsiednim monitorze... ).
> No i ok. Co kto lubi.

Jasne. Korzystanie z różnych metod wymaga różnych podejść. To tak jak z 
uczeniem się języka zupełnie innego koncepcyjnie. Nauczono Cię 
programowania liniowego, to podejście OOP staje się ekstremalnie trudne.

> Odświeżanie można zautomatyzować.
> Np. 
> https://chrome.google.com/webstore/detail/easy-auto-refresh/aabcgdmkeabbnleenpncegpcngjpnjkc?hl=pl 

Do bani. Chodzi o to, że ma się odświeżać gdy coś zmienisz w kodzie. A 
jeśli podzielisz plik na drobne, nie posiadające pełnej semantyki pliki 
HTML, to w życiu tego nie wyświetlisz na niczym.

Problem jest zatem w założeniach. Ty wolisz podzielić istniejący plik 
HTML na małe fragmenty (nazwijmy je views) a ja wolę w tych vewsach dać 
pełną strukturę kodu (balde w Laravelu wytnie sobie co trzeba) po to by 
móc wizualnie pracować.

> Jak nie, jak tak? :)
> Zmieniam treść stopki w jednym pliku i niezależnie jak dużo witryna ma 
> podstron, to ta zmiana widoczna jest na wszystkich.
> Magia?

Dobra, nie mogę komentować dłużej bo flejm się tworzy. Mamy inne 
podejście. Ja staram się nie odcinać od wysiwyg, Ty unikasz tego jak 
ognia :-)

Chętnie bym podyskutował dłużej, ale zobacz o jakiej godzinie odpisuję a 
rano praca... Muszę przyciąć trochę, sorki.


-- 
Pozdrawiam,
Marek

[toc] | [prev] | [next] | [standalone]

#15926

W dniu 2018-12-17 o 23:55, Marek S pisze:
> W dniu 2018-12-16 o 23:12, Kviat pisze:
> 

(...)
>> Albo ja nadal czegoś nie rozumiem.
> 
> Tak, zauważyłem. Wyjaśniam. Te 30.000 produktów zwykle korzysta z 1 lub 
> kilku szablonów. Szablon to plik HTML z odpowiednimi specjalnymi tagami, 
> które określają nazwy sekcji, oznaczają sekcje podlegające edycji i te 
> nie podlegające. Z tego powstaje plik HTML będący z kolei szablonem (w 
> sensie frameworka tym razem) dla 10 tys produktów a inny dla 
> pozostałych. Nie ma zatem potrzeby tworzenia 30000 plików lecz w 
> praktyce jest ich kilka. Wszystkie one mogą mieć wspólne sekcje jak 
> linki do CSS/JS. Wtedy modyfikując tą sekcję w jednym pliku szablonu, 
> zmieniamy wszystkie zależne pliki HTML.

(...)
>> A jak chcesz zmienić coś/treść w stopce? To zamiast mieć jeden 
>> plik-szablon ze stopką, to nanosisz zmianę w DW, włączasz ten update 
>> (czy jak to tam się nazywa) i w każdym z 30 tys plików html z 
>> produktami ten DW  nanosi zmianę automagicznie (automatycznie, skoro 
>> tak wolisz). A potem pchasz te 30 tys. zmienionych html-ów na docelowy 
>> serwer?
> 
> Tak. Oczywiście nie w takiej ilości. Duże projekty prowadzone tą metodą 
> miewały po kilkadziesiąt plików.

W sensie kilkudziesięciu plików-szablonów?
Czyli nie mając DW, dodanie linijki tekstu do stopki, która ma być 
identyczna na każdej podstronie, wiąże się z dodaniem ręcznie tej 
linijki do tych kilkudziesięciu plików-szablonów?

> Ale mniejsza o to. Zwróć uwagę na inny 
> aspekt. Masz frameworka, gdzie dzielisz jeden plik HTML na mnóstwo 
> małych viewsów itp. Plików takich masz powiedzmy 100. Każdy posiekany, 
> co daje sporo plików. Teraz webdesigner stwierdza, że zamiast jakiegoś 
> DIVa dajemy 4. Każdy z tych view musi być zmieniony.
> Robisz to na 
> piechotę. Tydzień roboty z korektą pomyłek zamiast 1 kliknięcie.

Albo może ktoś źle posiekał na viewsy, skoro trzeba zmieniać 100 plików...

>> Nie mieszajmy dwóch rzeczy. Teraz próbujesz wykazać większą wygodę 
>> pracy w edytorze wysiwyg, gdzie podgląd masz w tym narzędziu, zamiast 
>> podglądu w przeglądarce (albo w kilku różnych przeglądarkach 
>> równocześnie na sąsiednim monitorze... ).
>> No i ok. Co kto lubi.

(...)

> Dobra, nie mogę komentować dłużej bo flejm się tworzy. Mamy inne 
> podejście. Ja staram się nie odcinać od wysiwyg, Ty unikasz tego jak 
> ognia :-)

Nic takiego nie napisałem.
Jest mi to obojętne w czym frontendowiec robi szablon, czy w notatniku, 
czy w jego ulubionym super-hiper-duper-wypas edytorze wysiwyg.

Ale jak widzę, że na każdej ze stu podstron jest identyczna stopka, to 
nie tworzę sto viewsów ze stopką, tylko jeden.

> Chętnie bym podyskutował dłużej, ale zobacz o jakiej godzinie odpisuję a 
> rano praca... Muszę przyciąć trochę, sorki.

Raczej nie zgubię wątku, gdy będziesz odpowiadał kiedy masz czas i ochotę :)

Pozdrawiam
Piotr

[toc] | [prev] | [next] | [standalone]

#15930

W dniu 2018-12-18 o 10:24, Kviat pisze:

>> Tak. Oczywiście nie w takiej ilości. Duże projekty prowadzone tą 
>> metodą miewały po kilkadziesiąt plików.
> 
> W sensie kilkudziesięciu plików-szablonów?
> Czyli nie mając DW, dodanie linijki tekstu do stopki, która ma być 
> identyczna na każdej podstronie, wiąże się z dodaniem ręcznie tej 
> linijki do tych kilkudziesięciu plików-szablonów?

Można i tak. Ale zazwyczaj CMS odpowiada za treść stopki. Tak więc w 
stopce osobiście umieściłbym generator jej treści. Ale forma stopki 
narzucana byłaby przez szablon.

> Albo może ktoś źle posiekał na viewsy, skoro trzeba zmieniać 100 plików...

Właśnie! Więc masz źle posiekany projekt i co dalej?

>> Dobra, nie mogę komentować dłużej bo flejm się tworzy. Mamy inne 
>> podejście. Ja staram się nie odcinać od wysiwyg, Ty unikasz tego jak 
>> ognia :-)
> 
> Nic takiego nie napisałem.

Jak to nie? Cały czas to manifestujesz choć nie wprost. Jeśli wyrwiesz z 
projektu HTML/CSS/JS jakikolwiek fragment - np. wspomnianą powyżej 
stopkę dokumentu i umieścisz ją w oddzielnym pliku nie zawierającym 
<body> czy <html> to właśnie zrywasz z wysiwyg. Czy to nie hipokryzja? :-)

> Ale jak widzę, że na każdej ze stu podstron jest identyczna stopka, to 
> nie tworzę sto viewsów ze stopką, tylko jeden.

I o tym właśnie mowa. Całkowita izolacja od wysiwyg. Tymczasem ja 
preferowałbym trzymanie nadmiarowości kodu HTML po to by zachować 
wysiwyg. Ja rozumiem takie podejście. Nazywam to podejściem kodera. 
Pracuję jako full stack + graphic designer więc siłą rzeczy staram się 
godzić zwaśnione strony - grafika i kodera.

>> Chętnie bym podyskutował dłużej, ale zobacz o jakiej godzinie odpisuję 
>> a rano praca... Muszę przyciąć trochę, sorki.
> 
> Raczej nie zgubię wątku, gdy będziesz odpowiadał kiedy masz czas i 
> ochotę :)

Dziękuję :-) I sorki raz jeszcze za taki styl korespondencji. Doba nie 
da się wydłużyć. Jeśli coś ucieknie tematycznie poza zakres dyskusji - 
obetnę z w/w względu.

-- 
Pozdrawiam,
Marek

[toc] | [prev] | [next] | [standalone]

#15936

W dniu 2018-12-18 o 21:52, Marek S pisze:
> W dniu 2018-12-18 o 10:24, Kviat pisze:
> 
>>> Tak. Oczywiście nie w takiej ilości. Duże projekty prowadzone tą 
>>> metodą miewały po kilkadziesiąt plików.
>>
>> W sensie kilkudziesięciu plików-szablonów?
>> Czyli nie mając DW, dodanie linijki tekstu do stopki, która ma być 
>> identyczna na każdej podstronie, wiąże się z dodaniem ręcznie tej 
>> linijki do tych kilkudziesięciu plików-szablonów?
> 
> Można i tak. Ale zazwyczaj CMS odpowiada za treść stopki.

Ok. Wyraziłem się nieprecyzyjnie. Założyłem, że rozmawiamy o szablonie i
nie miałem na myśli treści z CMS.
Chodziło mi o zmianę czegoś (czegokolwiek), kawałka kodu szablonu (też 
tekst...) we fragmencie szablonu stopki.

> Tak więc w 
> stopce osobiście umieściłbym generator jej treści. Ale forma stopki 
> narzucana byłaby przez szablon.

Tak czy inaczej, skoro już wyżej sprostowałem słowo "tekst", zmiany 
trzeba by było dokonywać w kilkudziesięciu plikach ręcznie.
Chociażby dodanie drugiego generatora, obok tego już istniejącego (albo 
w innym miejscu).

>> Albo może ktoś źle posiekał na viewsy, skoro trzeba zmieniać 100 
>> plików...
> 
> Właśnie! Więc masz źle posiekany projekt i co dalej?

Więc jak już taki mam, to trudno. Mus, to mus. Doprowadziłbym sieczkę do 
porządku, albo zmieniłbym te sto plików i uciekał z takiego projektu 
tam, gdzie pieprz rośnie najszybciej jak się da.

Źle posiekany projekt to patologia - w skrócie, nie jest normą, jest to 
zła praktyka.

Ty swoją metodę określasz jako dobrą praktykę, więc nie rozumiem Twojego 
porównania tej Twojej dobrej praktyki, w której trzeba zmieniać 
kilkadziesiąt stopek w kilkudziesięciu plikach, do złej praktyki, w 
której trzeba zrobić to samo.
To czym ten źle posiekany na widoki projekt różni się od Twojego 
dobrego, skoro trzeba zrobić to samo dla tego samego efektu?

W dobrze pociętym na widoki szablonie nie trzeba zmieniać 
kilkudziesięciu plików stopek. W Twoim "dobrym" szablonie składającym 
się z kilkudziesięciu kompletnych plików html trzeba.

(Nie wątpię, że można trafić na szablon, który nie chce dać się dobrze 
pociąć na widoki, ale wtedy przeprowadza się rozmowę z frontendowcem, 
żeby zdobił tak, żeby się dało, albo się zmienia frontendowaca na 
takiego, który to potrafi i rozumie o co chodzi).

>>> Dobra, nie mogę komentować dłużej bo flejm się tworzy. Mamy inne 
>>> podejście. Ja staram się nie odcinać od wysiwyg, Ty unikasz tego jak 
>>> ognia :-)
>>
>> Nic takiego nie napisałem.
> 
> Jak to nie? Cały czas to manifestujesz choć nie wprost.

Nie wiem skąd taki wniosek wyciągnąłeś...
Ostatnio robiłem projekt dla jakiejś firmy, szablon zamówiony został w 
firmie zewnętrznej, która specjalizuje się w robieniu szablonów.

Bladego pojęcia nie mam w czym ten szablon robili. Czy w notatniku, czy 
w super-hiper edytorze wysiwyg. Dla mnie nie ma to kompletnie znaczenia.
Ale jak trzeba coś zmienić w jakimś elemencie, to nie muszę zmieniać 
tego w kilkudziesięciu plikach.

Nie mam nic do wysiwyg. Interesuje mnie poprawność tego co powstało, a 
nie jak powstało.

> Jeśli wyrwiesz z 
> projektu HTML/CSS/JS jakikolwiek fragment - np. wspomnianą powyżej 
> stopkę dokumentu i umieścisz ją w oddzielnym pliku nie zawierającym 
> <body> czy <html> to właśnie zrywasz z wysiwyg. Czy to nie hipokryzja? :-)

Nie, to nie jest hipokryzja. Po prostu mieszasz dwie różne warstwy.
Nie wiem czy zapomniałeś, ale jesteś na grupie od php...

Przykład, (skrajnie uproszczony, dla zrozumienia zasady) w projekcie mam 
pocięty szablon na widoki i pod widoki itd.

nagłówek
menu
środek
newsy
stopka itd.

Jeżeli mam pięć różnych podstron na których znajdują się newsy, i w tych 
newsach trzeba coś zmienić, to zmianę nanoszę tylko w jednym pliku, a 
nie w pięciu plikach z szablonami tych pięciu podstron.

Potrzeba zmienić coś w stopce - zmieniam widok stopki. Robię to raz, w 
jednym pliku, a nie w kilkudziesięciu plikach.
Nie muszę mieć żadnego narzędzia do "updejtowania" zmian na 
kilkadziesiąt plików.

A czy twórca szablonu nanosi/testuje sobie poprawki w notatniku w samej 
stopce, czy w notatniku na kompletnym pliku html, czy wreszcie w 
edytorze wysiwyg, kompletnie mnie nie interesuje.

>> Ale jak widzę, że na każdej ze stu podstron jest identyczna stopka, to 
>> nie tworzę sto viewsów ze stopką, tylko jeden.
> 
> I o tym właśnie mowa. Całkowita izolacja od wysiwyg.

Dla mnie, sto plików-szablonów z identyczną stopką, to sto zmian w stu 
plikach.
W tym sensie zapewne jest to kompletna izolacja od wysiwyg :)

> Tymczasem ja 
> preferowałbym trzymanie nadmiarowości kodu HTML po to by zachować 
> wysiwyg.

Tymczasem ja preferuję wyrzucać powtarzalne fragmenty kodu do osobnego 
pliku i mieć jeden taki fragment w jednym miejscu, zamiast powielony w 
kilkudziesięciu.
Gdybym robił inaczej, to po trzech miesiącach nie byłbym wstanie tego 
ogarnąć. Nie wspominając o osobach, które miałyby po mnie to przejąć, 
albo w przyszłości coś zmieniać.

> Ja rozumiem takie podejście. Nazywam to podejściem kodera. 

A jest jakieś inne, skoro o kodowaniu mowa? ;)

> Pracuję jako full stack + graphic designer więc siłą rzeczy staram się 
> godzić zwaśnione strony - grafika i kodera.

No nie chciałbym po Tobie przejmować projektu. Nie chciałoby mi się 
kupować DW, żeby zrobić zmianę w stopce :)

Pozdrawiam
Piotr

[toc] | [prev] | [next] | [standalone]

#15941

W dniu 2018-12-19 o 02:45, Kviat pisze:

> Jeżeli mam pięć różnych podstron na których znajdują się newsy, i w tych 
> newsach trzeba coś zmienić, to zmianę nanoszę tylko w jednym pliku, a 
> nie w pięciu plikach z szablonami tych pięciu podstron.
> 
> Potrzeba zmienić coś w stopce - zmieniam widok stopki. Robię to raz, w 
> jednym pliku, a nie w kilkudziesięciu plikach.
> Nie muszę mieć żadnego narzędzia do "updejtowania" zmian na 
> kilkadziesiąt plików.

Dobra, to od początku, Ja również nie jestem w swoim podejściu 
zobligowany do aktualizowania wszystkich plików - mogę jeden i będzie 
działało, ale kompletnie nie o to chodzi. Zobrazuję to na konkretnym 
przykładzie. Niech istnieje projekt:

<html>
<head>
...
<head>
<body>
<div>ten blok jest dla view #1<div>
<div>ten blok jest dla view #2<div>
<footer>to jest stopka będąca de facto view #3</footer>
</body>
</html>

Teraz np. w Laravelu robi się jak poniżej "Twoim sposobem":

Layout jest taki:
<html>
<head>
@yield("content1")
@yield("content2")
@yield("content3")
<head>
<body>

Plik view (w uproszczeniu - bez angażowania się w obsługę kontrolerów 
itp) będzie następujące:

@extends("home")
@section("content1")
<div>ten blok jest dla view #1<div>
@endsection("content")

@section("content2")
<div>ten blok jest dla view #2<div>
@endsection("content2")

@section("content3")
<footer>to jest stopka będąca de facto view #3</footer>
@endsection("content3")

Skupmy się na powyższym kodzie. Przychodzi do pracy Webdesigner, który 
nie ma pojęcia a PHP i frameworkach. Domyśla się, że trzeba zachować 
magiczne zaklęcia w kodzie HTML. Otwiera powyższy kod i niczego nie 
widzi bo dokument nie jest w pełni wartościowym dokumentem. A komu 
szkodziłoby zrobienie czegoś takiego jak niżej?

<html>
<head>
...
<head>
<body>
@extends("home")
@section("content1")
<div>ten blok jest dla view #1<div>
@endsection("content")

@section("content2")
<div>ten blok jest dla view #2<div>
@endsection("content2")

@section("content3")
<footer>to jest stopka będąca de facto view #3</footer>
@endsection("content3")
<head>
<body>

Taki kod zadziała i we frameworku i nieobyty w programowaniu webdesigner 
zobaczy pełny układ strony w swoim edytorze wysiwyg. Będzie mógł 
wizualnie w nim grzebać. W moim podejściu byłoby stworzenie kodu jak 
powyżej, zapisanie go gdzieś na boku projektu (nie uploadowany folder na 
serwer produkcyjny), dokonywanie zmian na tym jednym pliku, bo żywcem 
widzimy w nim wszelkie sekcje, a potem propagowanie zmian po wszystkich 
100 viewsach bazujących na tym projekcie.

Intencja jest taka, że narzędzie programistyczne takie jak DW potrafi 
propagować zmiany w poszczególnych sekcjach z zachowaniem tego czym we 
viewsach te sekcje zostały wypełnione. Czyli jeśli viewsy zawierają 
specyficzne znaczniki typu @section("content3"), to DW je tam pozostawi.

Aby było jeszcze klarowniej: webdesigner zmieni <div>ten blok jest dla 
view #2<div> na <div class="dupa">ten blok jest dla view #2<div>, to 
tylko zmieni się ten div a znaczniki charakterystyczne dla frameworku 
pozostaną nietknięte.

W niczym nie przeszkadza uzupełnianie kodu każdego viewsa o dodatkowy 
kod HTML. Usprawnia to także tworzenie viewsów bo w przypadku gdy 
webdesigner zmieni <div> na <cokolwiek> to programista musiałby we 
wszystkich viewsach to zmienić ręcznie. A po co skoro może w zamian nic 
nie robić?

-- 
Pozdrawiam,
Marek

[toc] | [prev] | [next] | [standalone]

#15957

Dnia Sat, 22 Dec 2018 20:48:21 +0100, Marek S napisał(a):

> Taki kod zadziała i we frameworku i nieobyty w programowaniu webdesigner 
> zobaczy pełny układ strony w swoim edytorze wysiwyg.

Skoro nieobyty, to powinien nadgonić obecne trendy. Szybko będzie potrafił
wprowadzać zmiany bez konieczności oglądania każdego piksela na ekranie po
trzy razy.

> Intencja jest taka, że narzędzie programistyczne takie jak DW potrafi 
> propagować zmiany w poszczególnych sekcjach z zachowaniem tego czym we 
> viewsach te sekcje zostały wypełnione. Czyli jeśli viewsy zawierają 
> specyficzne znaczniki typu @section("content3"), to DW je tam pozostawi.

Tak, to wszycy zrozumieli. I próbują Ci wyjaśnić, że to nie jest najlepszy
tryb pracy, zwłaszcza w zespole. Trzymasz się uparcie swojego
przyzwyczajenia pielęgnowanego przez lata, co nie jest niczym dziwnym, ale
spróbuj popracować dłużej jak reszta świata i wrócimy do tematu.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

[toc] | [prev] | [next] | [standalone]

#15964

W dniu 2018-12-26 o 17:43, Borys Pogoreło pisze:

> Tak, to wszycy zrozumieli. I próbują Ci wyjaśnić, że to nie jest najlepszy
> tryb pracy, zwłaszcza w zespole. Trzymasz się uparcie swojego
> przyzwyczajenia pielęgnowanego przez lata, co nie jest niczym dziwnym, ale
> spróbuj popracować dłużej jak reszta świata i wrócimy do tematu.

Ależ ja pracuję w ten sposób choćby dlatego, że nie mam wyboru. 
Wystarczyło powiedzieć, ze nie ma takiej opcji i temat byłby zamknięty.

Dostosowuję się do edytorów jakie używane są przez team - czyli NetBeans 
lub PHPStorm. W tym pierwszym mam spore doświadczenia z innych projektów 
a PHPStorm wybieram m.in. bo NetBeans krzaczył kod PHP napisany w 
PHPStorm, co w drugą stronę nie występuje.

-- 
Pozdrawiam,
Marek

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | pl.comp.lang.php

csiph-web