🚀 go-pugleaf

Dnia Sun, 16 Dec 2018 01:13:30 +0100, Marek S napisał(a):

> Problem dotyczy pracy z PHP-framewokami. Chciałbym aby zmiana wzorca 
> natychmiast była propagowana w danym projekcie. Jak to uczynić?

Mam wrażenie, że próbujesz sobie strzelić w stopę. Co dokładnie chcesz
uzyskać?

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

W dniu 2018-12-16 o 12:30, Borys Pogoreło pisze:
> Dnia Sun, 16 Dec 2018 01:13:30 +0100, Marek S napisał(a):
> 
>> Problem dotyczy pracy z PHP-framewokami. Chciałbym aby zmiana wzorca
>> natychmiast była propagowana w danym projekcie. Jak to uczynić?
> 
> Mam wrażenie, że próbujesz sobie strzelić w stopę. Co dokładnie chcesz
> uzyskać?
> 

Przykładowo jest strona WWW, dla uproszczenia rozważań: statyczna, 
zawierająca 50 podstron. Powiedzmy mają one u góry takie samo logo, 
menu, banner. Po środku jest miejsce na treści zależne od podstrony. Na 
dole stopka wspólna dla wszystkich stron.

W pewnym momencie klient mówi: a teraz dostaw Google Analytics. 
Chciałbym wejść w template, dopisać kod, kliknąć "publikuj" i wszystkie 
50 stron bazujących na tym templacie zyska dodatkowy fragment kodu.

Nie chcę żadnych SSI bo wtedy nie widzę całej struktury strony i muszę 
sobie ją wyobrażać. Chciałbym też aby klasy CSS były dostępne w trakcie 
edycji itp. W Dreamwearze dziesiątki jeśli nie setki projektów tak 
zrealizowałem i nigdy nie odczułem efektu strzału w stopę.

Jeśli uporamy się z tematem j/w to przeniosę go na programowanie 
frameworków.

-- 
Pozdrawiam,
Marek

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

> W pewnym momencie klient mówi: a teraz dostaw Google Analytics. 
> Chciałbym wejść w template, dopisać kod, kliknąć "publikuj" i wszystkie 
> 50 stron bazujących na tym templacie zyska dodatkowy fragment kodu.

1. To masz szablon bazowy gdzie masz te logo
2. Alternatywnie masz re-używalny blok do tego szablonu.

W żadnym wypadku nie jest to sprawa dla edytora, tylko kwestia
tego jak Ty zorganizujesz sobie kod.

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

W dniu 2018-12-16 o 16:33, Marek S pisze:
> W dniu 2018-12-16 o 12:30, Borys Pogoreło pisze:
>> Dnia Sun, 16 Dec 2018 01:13:30 +0100, Marek S napisał(a):
>>
>>> Problem dotyczy pracy z PHP-framewokami. Chciałbym aby zmiana wzorca
>>> natychmiast była propagowana w danym projekcie. Jak to uczynić?
>>
>> Mam wrażenie, że próbujesz sobie strzelić w stopę. Co dokładnie chcesz
>> uzyskać?
>>
> 
> Przykładowo jest strona WWW, dla uproszczenia rozważań: statyczna, 
> zawierająca 50 podstron. Powiedzmy mają one u góry takie samo logo, 
> menu, banner. Po środku jest miejsce na treści zależne od podstrony. Na 
> dole stopka wspólna dla wszystkich stron.
> 
> W pewnym momencie klient mówi: a teraz dostaw Google Analytics. 
> Chciałbym wejść w template, dopisać kod, kliknąć "publikuj" i wszystkie 
> 50 stron bazujących na tym templacie zyska dodatkowy fragment kodu.

Czy ja dobrze zrozumiałem, że jak chcesz coś dodać/zmienić np. w stopce, 
to oczekujesz automagicznej zmiany we wszystkich 50 stopkach we 
wszystkich 50 podstronach? Albo jak zmienisz menu, to we wszystkich 50 
menu na 50 podstronach?

> Nie chcę żadnych SSI bo wtedy nie widzę całej struktury strony i muszę 
> sobie ją wyobrażać.

Hmmmm... więc lepiej jest trzymać osobnych 50 podstron ze wszystkimi 
powtarzającymi się fragmentami, zamiast powtarzające się fragmenty 
wyrzucić do osobnego (osobnych) jednego pliku i go inkludować?
Nie jest prościej zmiany dokonać w jednym pliku?

Albo faktycznie próbujesz strzelać sobie w stopę, albo nie zrozumiałem 
idei Twojego pomysłu.

Pozdrawiam
Piotr

W dniu 2018-12-16 o 17:03, Kviat pisze:

> Czy ja dobrze zrozumiałem, że jak chcesz coś dodać/zmienić np. w stopce, 
> to oczekujesz automagicznej zmiany we wszystkich 50 stopkach we 
> wszystkich 50 podstronach? Albo jak zmienisz menu, to we wszystkich 50 
> menu na 50 podstronach?

Dokładnie tak.

> 
> Hmmmm... więc lepiej jest trzymać osobnych 50 podstron ze wszystkimi 
> powtarzającymi się fragmentami, zamiast powtarzające się fragmenty 
> wyrzucić do osobnego (osobnych) jednego pliku i go inkludować?
> Nie jest prościej zmiany dokonać w jednym pliku?

Po pierwsze - przy pracy z template'ami w DW właśnie w jednym pliku 
dokonujesz zmiany a na 50ciu widoczny jest tego efekt w "magiczny", jak 
to określasz, sposób.

Po drugie - niby co się dzieje jeśli zbierasz kawałki kodu z kilku 
plików? Właśnie to, że w rezultacie i tak otrzymasz kompletny jeden plik 
HTML, który wysyłasz do przeglądarki więc oszczędności nie ma żadnej.

Po trzecie te powtarzające się fragmenty mają jedną korzyść: _zawsze_ 
widzisz pełną stronę. Możesz śledzić wizualne zmiany w przeglądarce. A 
jeśli projekt został posiekany na kilka kawałków, to nie masz bladego 
pojęcia jak będzie wyglądała np. kolumna newsów do momentu kiedy serwer 
nie poskłada projektu do kupy. Takie budowanie WWW po omacku nie jest 
dobrą praktyką. Gdy po roku zajrzysz w swój własny projekt to zwykle 
rozpoczynasz od poszukiwań fragmentów kodu zamiast od razu wizualnie 
zobaczyć dany fragment wizualnie. A gdy programista generuje HTML jako 
składany string po kawałku w PHP, to już w ogóle katastrofa.

> 
> Albo faktycznie próbujesz strzelać sobie w stopę, albo nie zrozumiałem 
> idei Twojego pomysłu.

Nie tylko mojego ale i Adobe:
https://helpx.adobe.com/dreamweaver/user-guide.html?topic=/dreamweaver/morehelp/templates.ug.js

-- 
Pozdrawiam,
Marek

W dniu 2018-12-16 o 17:02, Wojciech Bancer pisze:
> On 2018-12-16, Marek S <precz@spamowi.com> wrote:
> 
>> W pewnym momencie klient mówi: a teraz dostaw Google Analytics.
>> Chciałbym wejść w template, dopisać kod, kliknąć "publikuj" i wszystkie
>> 50 stron bazujących na tym templacie zyska dodatkowy fragment kodu.
> 
> 1. To masz szablon bazowy gdzie masz te logo
> 2. Alternatywnie masz re-używalny blok do tego szablonu.
> 
> W żadnym wypadku nie jest to sprawa dla edytora, tylko kwestia
> tego jak Ty zorganizujesz sobie kod.

Nie wiem czy dobrze się rozumiemy: jak robisz wizualny podgląd takiego 
kodu HTML? Czy webdesigner nie znający PHP jest w stanie łatwo zobaczyć 
całość strony i nanieść poprawki?

-- 
Pozdrawiam,
Marek

Dnia Sun, 16 Dec 2018 17:25:16 +0100, Marek S napisał(a):

>> Czy ja dobrze zrozumiałem, że jak chcesz coś dodać/zmienić np. w stopce, 
>> to oczekujesz automagicznej zmiany we wszystkich 50 stopkach we 
>> wszystkich 50 podstronach? Albo jak zmienisz menu, to we wszystkich 50 
>> menu na 50 podstronach?
> 
> Dokładnie tak.

Czyli tak jak podejrzewałem, próbujesz sobie strzelić w stopę, choć
korzytając z Laravela masz dostęp do całkiem wygodnego mechanizmu szablonów
Blade.

> Po pierwsze - przy pracy z template'ami w DW właśnie w jednym pliku 
> dokonujesz zmiany a na 50ciu widoczny jest tego efekt w "magiczny", jak 
> to określasz, sposób.

I to są podstawy mechanizmu szablonów. Jeden plik bazowy, uzupełniany
fragmentami (również powtaralnymi) zawierającymi kolejne fragmenty. A cała
reszta to zarządzanie tym i wypełnianie treścią.

> Po trzecie te powtarzające się fragmenty mają jedną korzyść: _zawsze_ 
> widzisz pełną stronę. Możesz śledzić wizualne zmiany w przeglądarce. 

W przeglądarce się ogląda gotowy efekt, a nie półprodukty. Które do tego
nie są wypełnione docelową treścią, więc finalny wygląd może być skrajnie
inny.

> Nie tylko mojego ale i Adobe:
> https://helpx.adobe.com/dreamweaver/user-guide.html?topic=/dreamweaver/morehelp/templates.ug.js

To są jakieś zaszłości z lat 90, gdy taka funkcjonalność jeszcze miała
rację bytu, a strony rzeźbiło się z plików HTML.

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

Dnia Sun, 16 Dec 2018 17:27:49 +0100, Marek S napisał(a):

> Nie wiem czy dobrze się rozumiemy: jak robisz wizualny podgląd takiego 
> kodu HTML? Czy webdesigner nie znający PHP jest w stanie łatwo zobaczyć 
> całość strony i nanieść poprawki?

Jeśli nie zatrzymał z umiejętnościami w ubiegłym wieku, to tak - będzie w
stanie nanieść poprawki.

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

W dniu 2018-12-16 o 17:25, Marek S pisze:
> W dniu 2018-12-16 o 17:03, Kviat pisze:
> 
>> Czy ja dobrze zrozumiałem, że jak chcesz coś dodać/zmienić np. w 
>> stopce, to oczekujesz automagicznej zmiany we wszystkich 50 stopkach 
>> we wszystkich 50 podstronach? Albo jak zmienisz menu, to we wszystkich 
>> 50 menu na 50 podstronach?
> 
> Dokładnie tak.
> 
>>
>> Hmmmm... więc lepiej jest trzymać osobnych 50 podstron ze wszystkimi 
>> powtarzającymi się fragmentami, zamiast powtarzające się fragmenty 
>> wyrzucić do osobnego (osobnych) jednego pliku i go inkludować?
>> Nie jest prościej zmiany dokonać w jednym pliku?
> 
> Po pierwsze - przy pracy z template'ami w DW właśnie w jednym pliku 
> dokonujesz zmiany a na 50ciu widoczny jest tego efekt w "magiczny", jak 
> to określasz, sposób.

Jest widoczny, bo zamiast ręcznie nanosić zmiany w 50 plikach, ten DW 
zrobił to za Ciebie.

I uważasz, że to jest właściwa praktyka?
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ę.

> Po drugie - niby co się dzieje jeśli zbierasz kawałki kodu z kilku 
> plików? Właśnie to, że w rezultacie i tak otrzymasz kompletny jeden plik 
> HTML, który wysyłasz do przeglądarki więc oszczędności nie ma żadnej.

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

> Po trzecie te powtarzające się fragmenty mają jedną korzyść: _zawsze_ 
> widzisz pełną stronę. Możesz śledzić wizualne zmiany w przeglądarce. A 
> jeśli projekt został posiekany na kilka kawałków, to nie masz bladego 
> pojęcia jak będzie wyglądała np. kolumna newsów do momentu kiedy serwer 
> nie poskłada projektu do kupy.

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...
Skoro ktoś nie ma bladego pojęcia, to może niech się lepiej za to nie 
zabiera, co? :)
Być może takie dodawanie identycznych zmian do każdego pliku sprawdza 
się gdy masz do ogarnięcia "wizytówkę" firmy składającej się z trzech 
podstron na krzyż. No może, jak masz podstron 50, to kupujesz jakiegoś DW...

> Takie budowanie WWW po omacku nie jest 
> dobrą praktyką.

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?

> Gdy po roku zajrzysz w swój własny projekt to zwykle 
> rozpoczynasz od poszukiwań fragmentów kodu zamiast od razu wizualnie 
> zobaczyć dany fragment wizualnie. A gdy programista generuje HTML jako 
> składany string po kawałku w PHP, to już w ogóle katastrofa.

Od tego są narzędzia, frameworki, systemy szablonów...
Gdyby tak jak piszesz, byłaby to katastrofa, to praktycznie wszystkie 
trochę większe projekty w php nie miałyby prawa działać.
Działają i mają się dobrze.

Osobiście, gdyby mi jakiś programista zaproponował metodę, którą tu 
forsujesz jako "dobrą praktykę", to co najwyżej mógłbym z nim pójść na 
piwo i rozejść się w zgodzie, ale w żadnym wypadku nie podjąłbym się 
współpracy przy stronie, która miałaby mieć więcej nić 3 podstrony.

>> Albo faktycznie próbujesz strzelać sobie w stopę, albo nie zrozumiałem 
>> idei Twojego pomysłu.
> 
> Nie tylko mojego ale i Adobe:
> https://helpx.adobe.com/dreamweaver/user-guide.html?topic=/dreamweaver/morehelp/templates.ug.js 

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 :)

Pozdrawiam
Piotr

W dniu 2018-12-16 o 17:45, Borys Pogoreło pisze:

> Jeśli nie zatrzymał z umiejętnościami w ubiegłym wieku, to tak - będzie w
> stanie nanieść poprawki.
> 

Czy mógłbyś mi wypunktować procedurę postępowania?  Żeby mega-uprościć, 
to robimy dwa dokumenty HTML + link do CSS, których jedna część kodu 
może podlegać edycji redakcyjnej a inna ma być wspólna i pochodzić ze 
wzorca.

Chciałbym osiągnąć coś takiego:
1. Zmieniamy coś we wzorcu, to aktualizowana jest treść obu stron.
2. Chcę widzieć offline'owo wszelkie zmiany w przeglądarce. Nie mamy 
XAMPP'a itp. Niech webdesigner zwyczajnie widzi graficzną reprezentację 
swojego kodu HTML/CSS.

Jak byś to zrobił w PHPStormie?

-- 
Pozdrawiam,
Marek

Dnia Sun, 16 Dec 2018 19:10:20 +0100, Marek S napisał(a):

> Czy mógłbyś mi wypunktować procedurę postępowania?  Żeby mega-uprościć, 
> to robimy dwa dokumenty HTML + link do CSS, których jedna część kodu 
> może podlegać edycji redakcyjnej a inna ma być wspólna i pochodzić ze 
> wzorca.

Ja Ci to nawet utrudnię. To co opisujesz powinno być raczej zbiorem
szablonów i plików LESS/SCSS kompilowanych do CSS. Dziś pliki HTML/CSS/JS
to tylko wynik znacznie bardziej skomplikowanego procesu.

> Chciałbym osiągnąć coś takiego:
> 1. Zmieniamy coś we wzorcu, to aktualizowana jest treść obu stron.
> 2. Chcę widzieć offline'owo wszelkie zmiany w przeglądarce. Nie mamy 
> XAMPP'a itp. Niech webdesigner zwyczajnie widzi graficzną reprezentację 
> swojego kodu HTML/CSS.

Absolutne minimum w dzisiejszych czasach to jakieś repozytorium i
uruchamianie z niego instancji testowej, gdzie designer może ocenić
wprowadzone zmiany (najlepiej automatyczne, ale na upartego i ręczne). 

A jeśli designer chce to odpalać lokalnie, to można mu zmontować jakiegoś
Dockera z obrazem aplikacji. Odpala i działa. Dla Laravela istnieje trochę
rozwiązań tego typu.

To co opisujesz to jest informatyczne średniowiecze.

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

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

> Czyli tak jak podejrzewałem, próbujesz sobie strzelić w stopę, choć
> korzytając z Laravela masz dostęp do całkiem wygodnego mechanizmu szablonów
> Blade.

Tylko, że nie stosujemy Laravela. Pytanie jest ogólne, dotyczące 
wyłącznie HTML/CSS z pominięciem tego, co w bacendzie siedzi.

Strzelić w stopę w sensie chęci używania takiego stylu pracy w PHPStorm, 
czy ogólnie? Bo, tak jak  napisałem, pod DW budujesz sobie szablony i 
podszablony w szablonach, a wszystko potem jest aktualizowane we 
wszystkich dokumentach HTML. Działa to bezbłędnie. Więc tam nie 
odnosiłem wrażenia strzelania w stopę.

> W przeglądarce się ogląda gotowy efekt, a nie półprodukty. Które do tego
> nie są wypełnione docelową treścią, więc finalny wygląd może być skrajnie
> inny.

Widzisz, a ja chcę widzieć wszystkie półprodukty wizualnie, bez 
testowania ich na całym projekcie. Jeśli projektuję tabelę, to chcę 
widzieć czy dobrałem odpowiednie kolory, paddingi etc. Nie chcę odpalać 
komponentu na projekcie bo i tak nie będzie on działał do czasu kiedy 
ktoś inny nie dopisze innego komponentu. Wolałbym strukturę HTML mieć 
wizualnie opracowaną.

> 
>> Nie tylko mojego ale i Adobe:
>> https://helpx.adobe.com/dreamweaver/user-guide.html?topic=/dreamweaver/morehelp/templates.ug.js
> 
> To są jakieś zaszłości z lat 90, gdy taka funkcjonalność jeszcze miała
> rację bytu, a strony rzeźbiło się z plików HTML.
> 

To kwestia SPOSOBU WYKORZYSTANIA NARZĘDZIA a nie samego narzędzia. W ten 
sposób budowałem bardzo złożone sklepy internetowe z konfiguratorami 
produktów, wyuzdanymi wyszukiwarkami itp. Mimo to zawsze widziałem 
projekt pod DW zanim zaczął on mieć jakąkolwiek funkcjonalność. Mało 
tego, nawet w wersji pociętej na wiele plików (np. dla MVC), każdy 
element składowy - np. wspomniana tabelka - była możliwa do obejrzenia 
wizualnego bo plik zawierał całość kodu HTML (nagłówki, link do CSS, JS 
itp) i tylko podczas renderowania strony pobierany był zaznaczony 
fragment pliku HTML jako źródło kodu HTML dla komponentu. Na każdym 
etapie było można łatwo poprawiać CSS/HTML i widzieć te poprawki bez 
uruchamiania aplikacji. Błyskawiczna praca.

Widzę, że w PHPStorm też jest plugin LiveEdit ale nie mam żadnego 
doświadczenia. Chciałbym przenieść moje doświadczenia z DW do PHPStorm, 
który jest o niebo lepszy od DW.

-- 
Pozdrawiam,
Marek

Dnia Sun, 16 Dec 2018 19:29:03 +0100, Marek S napisał(a):

> W dniu 2018-12-16 o 17:43, Borys Pogoreło pisze:
> 
> Strzelić w stopę w sensie chęci używania takiego stylu pracy w PHPStorm, 
> czy ogólnie? Bo, tak jak  napisałem, pod DW budujesz sobie szablony i 
> podszablony w szablonach, a wszystko potem jest aktualizowane we 
> wszystkich dokumentach HTML. Działa to bezbłędnie. Więc tam nie 
> odnosiłem wrażenia strzelania w stopę.

A jak jeden z tych plików ma zacząć wyglądać inaczej? Albo 10 z 50? A
później 35 innych jeszcze inaczej? Tworzysz nowy scenariusz dla każdego z
takich przypadków? I wszystkie osoby, które muszą pracować z tym kodem
również muszą to zrobić? Bo przy takim podejściu nieodłączną częścią
projektu jest konfiguracja IDE, co jest kompletnie nieakceptowalne.

> Widzisz, a ja chcę widzieć wszystkie półprodukty wizualnie, bez 
> testowania ich na całym projekcie. Jeśli projektuję tabelę, to chcę 
> widzieć czy dobrałem odpowiednie kolory, paddingi etc. Nie chcę odpalać 
> komponentu na projekcie bo i tak nie będzie on działał do czasu kiedy 
> ktoś inny nie dopisze innego komponentu. Wolałbym strukturę HTML mieć 
> wizualnie opracowaną.

Jeśli koniecznie chcesz pracować w ten sposób, to możesz sobie zrobić
szablon ogólny do testów, który będzie dołączał komponenty i je
wizualizował. To absolutnie żaden problem.

> To kwestia SPOSOBU WYKORZYSTANIA NARZĘDZIA a nie samego narzędzia. 

Kontynuując analogię - mam młotek i wszystko wygląda jak gwóźdź.

> Na każdym etapie było można łatwo poprawiać CSS/HTML i widzieć te
> poprawki bez uruchamiania aplikacji. Błyskawiczna praca.

Zrobisz to i z szablonami. Przyzwyczaiłeś się do konkretnego trybu pracy i
narzędzia, a do tego robiłeś to sam.

> Widzę, że w PHPStorm też jest plugin LiveEdit ale nie mam żadnego 
> doświadczenia. Chciałbym przenieść moje doświadczenia z DW do PHPStorm, 
> który jest o niebo lepszy od DW.

Nie rób tego. Wykorzystaj to jako okazję do nauki lepszych praktyk.

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

W dniu 2018-12-16 o 18:13, Kviat pisze:

>> Po pierwsze - przy pracy z template'ami w DW właśnie w jednym pliku 
>> dokonujesz zmiany a na 50ciu widoczny jest tego efekt w "magiczny", 
>> jak to określasz, sposób.
> 
> 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. Po to by wizualnie oceniać nanoszone zmiany. W ten sposób 
błyskawicznie dopieszczam HTML bez konieczności uruchamiania aplikacji. 
I wtedy w/w technika bardzo ułatwia np. dolinkowanie kolejnego CSS czy 
JS we wszystkich widokach. Bez tego mam dwa wyjścia:

1. Albo w 50 widokach ręcznie dodawać linki do CSS/JS gdy coś się zmieni.
2. Abo zrezygnować z wizualnego kodowania i testować wszystko na 
aplikacji, co czasem bywa czasochłonne bo zwykłe F5 nie zadziała np. na 
podsumowaniu zamówienia sklepu internetowego. Wtedy muszę nowe tworzyć 
by móc zobaczyć formatowanie.

> 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. Jeśli nie masz w domu spawarki, to młotkiem nie 
wykonasz tej samej pracy więc wtedy musisz zmienić podejście. Jednak 
brak spawarki nie powinien ograniczać wyobraźni lecz powinien skłonić do 
jej "doinstalowania" jeśli to kwestia kliknięcia.

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

Ja tymczasem preferuję przeciągnąć krawędź kolumny i na tym poprzestać. 
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. A w metodzie prób i błędów kopiesz się z koniem dochodząc do 
tego samego rezultatu po 30 odświeżeniach, czyszczeniach cache 
przeglądarki i frameworka. W/g mnie do bani jest praca na poziomie 
kodera dla uzyskania efektów estetycznych.

To przykład - nie wyjeżdżaj z argumentacją o stosowaniu innych jednostek 
itp.

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

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

> 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. 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. 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, który dało się wizualnie korygować bez stosowania metody 
prób i błędów.

-- 
Pozdrawiam,
Marek

W dniu 2018-12-16 o 19:21, Borys Pogoreło pisze:

> Ja Ci to nawet utrudnię. To co opisujesz powinno być raczej zbiorem
> szablonów i plików LESS/SCSS kompilowanych do CSS. Dziś pliki HTML/CSS/JS
> to tylko wynik znacznie bardziej skomplikowanego procesu.

Stosuję SCSS czy składanie JS w locie jedynie przy rozbudowanych 
aplikacjach. W przeciwnym razie jest to faktycznie, tak jak nazwałeś, 
utrudnianiem sobie życia.

 > To co opisujesz to jest informatyczne średniowiecze.

Być może wysiwyg jest średniowieczem ale bardzo efektywnym w porównaniu 
ze zgadywaniem wartości atrybutów CSS i sprawdzaniem na poziomie 
aplikacji czy ustawiliśmy je już dostatecznie estetycznie, czy jeszcze 
trzeba poprawić - i tak kilkanaście razy, jeśli nie więcej.

No ale ok. Zakładam, że uzyskałem odpowiedź w postaci, że PHPStorm nie 
będzie potrafił pracować w w/w schemacie więc odpuszczam sobie i robię 
tak jak inni: granat w kompletny kod HTML projektu i niech trafia do 
pierdyliona folderów po kawałku bez możliwości podglądu tego, co się robi.

-- 
Pozdrawiam,
Marek

W dniu 2018-12-16 o 19:53, Borys Pogoreło pisze:

> 
> A jak jeden z tych plików ma zacząć wyglądać inaczej? Albo 10 z 50? 

Proste, robi się dla tej grupy drugi szablon.

> A
> później 35 innych jeszcze inaczej? 

Wtedy oznacza to, że do zaprojektowania graficznego aplikacji 
zatrudniono programistę zamiast grafika - projektanta stron WWW. Czyli 
błąd krytyczny :-)


> Tworzysz nowy scenariusz dla każdego z
> takich przypadków? I wszystkie osoby, które muszą pracować z tym kodem
> również muszą to zrobić? Bo przy takim podejściu nieodłączną częścią
> projektu jest konfiguracja IDE, co jest kompletnie nieakceptowalne.

No coś Ty! DW ma kompletne narzędzia do VCS - w tym Git oraz 
synchronizowania plików między członkami zespołu. To wszystko samo się 
może dziać lub być monitorowane. Pliki szablonów są dla DW takimi samymi 
składowymi projektu jak blade dla Laravela.

Jak już komuś napisałem: projekty w PHPStorm nie przeniosły się 
bezproblemowo do NetBeansa. Więc to co dla Ciebie nie jest akceptowalne, 
w życiu realnym zdarza się.

> Jeśli koniecznie chcesz pracować w ten sposób, to możesz sobie zrobić
> szablon ogólny do testów, który będzie dołączał komponenty i je
> wizualizował. To absolutnie żaden problem.

Tak właśnie chcę obejść problem skoro się nie da inaczej. Komponenty 
będę sobie rzeźbił na boku po prostu ... ale wtedy będzie kłopot z 
przenoszeniem działań do Laravelowych blade'ów, które mają w sobie 
struktury danych wszczepione. Zwykły copy & paste nie zadziała.
> 
> Zrobisz to i z szablonami. Przyzwyczaiłeś się do konkretnego trybu pracy i
> narzędzia, a do tego robiłeś to sam.

To prawda, że przyzwyczaiłem się do wysiwyg. Sam nie robiłem lecz w 
grupie. DW dobrze sprawdza się w teamie.

>> Widzę, że w PHPStorm też jest plugin LiveEdit ale nie mam żadnego
>> doświadczenia. Chciałbym przenieść moje doświadczenia z DW do PHPStorm,
>> który jest o niebo lepszy od DW.
> 
> Nie rób tego. Wykorzystaj to jako okazję do nauki lepszych praktyk.
> 

Ok, tak uczynię. Choć martwi mnie to, że będę musiał sporo czasu 
poświęcać na "przesuwanie po pikselu aż trafię". Wydaje mi się to trochę 
takim kodowaniem HTML/CSS (nie mówię o PHP) jak w notatniku. Póki co 
odbieram to jak wielki skok wstecz. Może cud nadejdzie i dostrzegę w tym 
nowoczesność i korzyść :-)

A'propos.
Teraz mnie naszło. Mam pewien kłopot, a raczej dwa. Skoro trzeba z 
palucha edytować HTML/CSS, to tak czynię. No i nie znalazłem opcji w 
ustawieniach, która włączyłaby podpowiadanie wartości atrybutów CSS. 
Konkretnie: nigdy nie pamiętam kolejności wartości box-shadow (spread z 
blurem mylę ciągle). Jak spowodować abym jakiegoś hinta dostał?

Druga rzecz: color picker. Czy w color pickerze jest szansa by zamiast 
hex'a dostać rgb()? Nie rgba lecz rgb. Póki co generuję hex i konwertuję 
do rgb.

-- 
Pozdrawiam,
Marek

Dnia Sun, 16 Dec 2018 20:53:35 +0100, Marek S napisał(a):

> No coś Ty! DW ma kompletne narzędzia do VCS - w tym Git oraz 
> synchronizowania plików między członkami zespołu. To wszystko samo się 
> może dziać lub być monitorowane. Pliki szablonów są dla DW takimi samymi 
> składowymi projektu jak blade dla Laravela.

Chodzi mi o to, że z taką konstrukcją projektu nie da sie efektywnie
pracować bez konkretnego edytora z konkretnym zestawem ustawień. A to nie
powinno mieć najmniejszego znaczenia dla kodu.

> Jak już komuś napisałem: projekty w PHPStorm nie przeniosły się 
> bezproblemowo do NetBeansa. Więc to co dla Ciebie nie jest akceptowalne, 
> w życiu realnym zdarza się.

To, że jeden edytor nie do końca rozumie ustawienia drugiego, to nic
dziwnego.

> Tak właśnie chcę obejść problem skoro się nie da inaczej. Komponenty 
> będę sobie rzeźbił na boku po prostu ... ale wtedy będzie kłopot z 
> przenoszeniem działań do Laravelowych blade'ów, które mają w sobie 
> struktury danych wszczepione. Zwykły copy & paste nie zadziała.

Da sie zrobić i tak jak chcesz nadpisując Renderer, ale to jest
skomplikowane rozwiązanie nieistniejącego problemu. Serio, spróbuj najpierw
tak, jak cały świat obecnie to robi.

> Ok, tak uczynię. Choć martwi mnie to, że będę musiał sporo czasu 
> poświęcać na "przesuwanie po pikselu aż trafię". Wydaje mi się to trochę 
> takim kodowaniem HTML/CSS (nie mówię o PHP) jak w notatniku. Póki co 
> odbieram to jak wielki skok wstecz. Może cud nadejdzie i dostrzegę w tym 
> nowoczesność i korzyść :-)

Layouty pixel-perfect dawno umarły, w RWD niewiele musi się zgadzać co do
piksela.

> A'propos. Teraz mnie naszło. Mam pewien kłopot, a raczej dwa. Skoro
> trzeba z palucha edytować HTML/CSS, to tak czynię. No i nie znalazłem
> opcji w ustawieniach, która włączyłaby podpowiadanie wartości atrybutów
> CSS. Konkretnie: nigdy nie pamiętam kolejności wartości box-shadow
> (spread z blurem mylę ciągle). Jak spowodować abym jakiegoś hinta
> dostał?

Kursor na własność i Ctrl + Q.

> Druga rzecz: color picker. Czy w color pickerze jest szansa by zamiast 
> hex'a dostać rgb()? Nie rgba lecz rgb. Póki co generuję hex i konwertuję 
> do rgb.

Kursor na kolor i lewy Alt + Enter.

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

Dnia Sun, 16 Dec 2018 20:11:23 +0100, Marek S napisał(a):

> 2. Abo zrezygnować z wizualnego kodowania i testować wszystko na 
> aplikacji, co czasem bywa czasochłonne bo zwykłe F5 nie zadziała np. na 
> podsumowaniu zamówienia sklepu internetowego. Wtedy muszę nowe tworzyć 
> by móc zobaczyć formatowanie.

To coś jest nie tak z tym podsumowaniem, skoro nie można go odświeżyć. To
nie jest strona, którą można zobaczyć tylko raz.

A do takich testów służy np. https://www.browsersync.io/

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

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?

> Ja tymczasem preferuję przeciągnąć krawędź kolumny i na tym poprzestać. 
> 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. A w metodzie prób i błędów kopiesz się z koniem dochodząc do 
> tego samego rezultatu po 30 odświeżeniach, czyszczeniach cache 
> przeglądarki i frameworka. W/g mnie do bani jest praca na poziomie 
> kodera dla uzyskania efektów estetycznych.

Skoro już zacząłeś pracować z sensownym frameworkiem, to zainteresuj sie od
razu SCSS. Wszystko co opisujesz możesz zmienić ustawiając inną wartość
jedej zmiennej.

> Owszem, to też racja. Ale tego nie unikniesz. 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.

Totalnie nie rozumiem problemu. Ctrl + Alt + L i masz sformatowany kod jak
tylko chcesz. Serio ktoś ręcznie rzeźbił takie poprawki, mając do
dyspozycji narzędzia?

> A korzyść taka iż każdy jeden widok otrzymałem jako pełnowartościowy 
> dokument HTML, który dało się wizualnie korygować bez stosowania metody 
> prób i błędów.

I na takich prostych przypadkach kończy się realna przydatność tej metody.

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

Dnia Sun, 16 Dec 2018 20:25:46 +0100, Marek S napisał(a):

> Stosuję SCSS czy składanie JS w locie jedynie przy rozbudowanych 
> aplikacjach. W przeciwnym razie jest to faktycznie, tak jak nazwałeś, 
> utrudnianiem sobie życia.

Dlaczego? File watcher w phpStorm + BrowserSync i nawet nie zauważasz, że
pracujesz z SCSS. Niezależnie od wielkości projektu.

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

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

On 2018-12-16, Borys Pogoreło <borys@pl.edu.leszno> wrote:

[...]

> A jeśli designer chce to odpalać lokalnie, to można mu zmontować jakiegoś
> Dockera z obrazem aplikacji. Odpala i działa. Dla Laravela istnieje trochę
> rozwiązań tego typu.
>
> To co opisujesz to jest informatyczne średniowiecze.

Ja tam bym poszedł w dobrze skonfigurowany browser-sync :)

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

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

[...]

> Być może wysiwyg jest średniowieczem ale bardzo efektywnym w porównaniu 
> ze zgadywaniem wartości atrybutów CSS i sprawdzaniem na poziomie 
> aplikacji czy ustawiliśmy je już dostatecznie estetycznie, czy jeszcze 
> trzeba poprawić - i tak kilkanaście razy, jeśli nie więcej.

Z niecierpliwością czekam na ten moment kiedy odkryjesz istnienie grafików
i produkowanych przez nich plików graficznych :-)

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

W dniu 2018-12-16 o 22:19, Borys Pogoreło pisze:
>> Stosuję SCSS czy składanie JS w locie jedynie przy rozbudowanych
>> aplikacjach. W przeciwnym razie jest to faktycznie, tak jak nazwałeś,
>> utrudnianiem sobie życia.
> 
> Dlaczego? File watcher w phpStorm + BrowserSync i nawet nie zauważasz, że
> pracujesz z SCSS. Niezależnie od wielkości projektu.

Zgoda, ale korzyści z tego też nie mam. Temat jest podobny do ładowania 
bibliotek jQuery w miejscu gdzie wystarczy jedna linijka kodu w czystym 
JS. Da się, ale po co?

Od czasu kiedy wprowadzono calc() itp do CSS coraz rzadziej dostrzegam 
korzyści z scss w małych projektach.

-- 
Pozdrawiam,
Marek

W dniu 2018-12-17 o 20:36, Wojciech Bancer pisze:
> On 2018-12-16, Marek S <precz@spamowi.com> wrote:
> 
> [...]
> 
>> Być może wysiwyg jest średniowieczem ale bardzo efektywnym w porównaniu
>> ze zgadywaniem wartości atrybutów CSS i sprawdzaniem na poziomie
>> aplikacji czy ustawiliśmy je już dostatecznie estetycznie, czy jeszcze
>> trzeba poprawić - i tak kilkanaście razy, jeśli nie więcej.
> 
> Z niecierpliwością czekam na ten moment kiedy odkryjesz istnienie grafików
> i produkowanych przez nich plików graficznych :-)

Chyba coś nie na temat albo nie nadążam.

-- 
Pozdrawiam,
Marek

W dniu 2018-12-16 o 22:09, Borys Pogoreło pisze:

> 
> Chodzi mi o to, że z taką konstrukcją projektu nie da sie efektywnie
> pracować bez konkretnego edytora z konkretnym zestawem ustawień. A to nie
> powinno mieć najmniejszego znaczenia dla kodu.

Tak, zrozumiałem i odpowiedziałem (poniżej), że z tym nierzadko są 
kłopoty bo edytory dorzucają od siebie wstawki albo niezrozumiałe dla 
innych edytorów (to pikuś) albo wręcz powodujące, że kod jest 
nieczytelny i bez dostosowania plików nie da się z nimi pracować.

> 
>> Jak już komuś napisałem: projekty w PHPStorm nie przeniosły się
>> bezproblemowo do NetBeansa. Więc to co dla Ciebie nie jest akceptowalne,
>> w życiu realnym zdarza się.
> 
> To, że jeden edytor nie do końca rozumie ustawienia drugiego, to nic
> dziwnego.

I właśnie to przeczy powyższemu w znacznej części.

> Da sie zrobić i tak jak chcesz nadpisując Renderer, ale to jest
> skomplikowane rozwiązanie nieistniejącego problemu. Serio, spróbuj najpierw
> tak, jak cały świat obecnie to robi.

...albo właśnie wpadłem na inny pomysł. W już tym generycznym projekcie 
zwyczajnie umieszczę wstawki języka blade. Wtedy modyfikacje w postaci 
np. "wstaw kolumnę do tabeli" będą poprawnie się wykonywały - o ile w 
PHPStorm da się wstawiać kolumnę. Tego jeszcze nie udało mi się 
namierzyć. A przy tabelach to ułatwia sprawę.

> Layouty pixel-perfect dawno umarły, w RWD niewiele musi się zgadzać co do
> piksela.

Użyłeś słowa klucz: niewiele.

>> A'propos. Teraz mnie naszło. Mam pewien kłopot, a raczej dwa. Skoro
>> trzeba z palucha edytować HTML/CSS, to tak czynię. No i nie znalazłem
>> opcji w ustawieniach, która włączyłaby podpowiadanie wartości atrybutów
>> CSS. Konkretnie: nigdy nie pamiętam kolejności wartości box-shadow
>> (spread z blurem mylę ciągle). Jak spowodować abym jakiegoś hinta
>> dostał?
> 
> Kursor na własność i Ctrl + Q.

To już próbowałem. Nie działa.
https://drive.google.com/file/d/19I0G4n1E1IosnkWpMhrb414CbeKUnci9/view?usp=sharing

Ctrl + P też nie.


> 
>> Druga rzecz: color picker. Czy w color pickerze jest szansa by zamiast
>> hex'a dostać rgb()? Nie rgba lecz rgb. Póki co generuję hex i konwertuję
>> do rgb.
> 
> Kursor na kolor i lewy Alt + Enter.

Ale to jest konwerter kolorów a nie kolor picker. Właśnie póki co 
najpierw ustalam kolor kolor pickerem a potem konwertuję bo color picker 
chyba nie potrafi zapisywać w żądanym formacie.

-- 
Pozdrawiam,
Marek

W dniu 2018-12-16 o 22:17, Borys Pogoreło pisze:

> To coś jest nie tak z tym podsumowaniem, skoro nie można go odświeżyć. To
> nie jest strona, którą można zobaczyć tylko raz.

Ok, może przykład nieprzemyślany ale wiesz w czym rzecz - nie każdą 
stronę da się odświeżyć.

> A do takich testów służy np. https://www.browsersync.io/

Hmm, na pierwszy rzut oka nie wiem z czym mam do czynienia :-(

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

Eeee... Co znaczy "ma powiększony sam tekst" albo "używa innego fontu"? 
Użytkownik nie grzebie po CSS.

Nie zawsze proporcje mają zastosowanie. Np. gdy mamy do czynienia z 
obiektami graficznymi (nawet w tle).


> Skoro już zacząłeś pracować z sensownym frameworkiem, to zainteresuj sie od
> razu SCSS. Wszystko co opisujesz możesz zmienić ustawiając inną wartość
> jedej zmiennej.

Pracuję w SCSS już od dawna. Nie ma znaczenia czy mam celować w piksele 
za pośrednictwem zmiennej czy bezpośrednio w CSS.

> Totalnie nie rozumiem problemu. Ctrl + Alt + L i masz sformatowany kod jak
> tylko chcesz. Serio ktoś ręcznie rzeźbił takie poprawki, mając do
> dyspozycji narzędzia?

Skrót nie działa w NetBeans. Nie rozumiesz o czym piszę. Code folding 
nanoszone przez PHPStorm rozwala nierzadko wizualnie kod pod NetBeans. 
NetBeans potrafi interpretować instrukcje foldingu lecz robi to źle gdy 
zostały wygenerowane przez PHPStorm.

> 
>> A korzyść taka iż każdy jeden widok otrzymałem jako pełnowartościowy
>> dokument HTML, który dało się wizualnie korygować bez stosowania metody
>> prób i błędów.
> 
> I na takich prostych przypadkach kończy się realna przydatność tej metody.

Tak! Właśnie! Trudno narzekać, że ma się młotek i nie pasuje do śrub. 
Trudno narzekać na wkrętak, że nie pasuje do gwoździ.

A tych przypadków jest całkiem sporo. A już w szczególności gdy poprawia 
się czyjeś stare projekty.

-- 
Pozdrawiam,
Marek

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

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

[...]

>>> aplikacji czy ustawiliśmy je już dostatecznie estetycznie, czy jeszcze
>>> trzeba poprawić - i tak kilkanaście razy, jeśli nie więcej.
>> 
>> Z niecierpliwością czekam na ten moment kiedy odkryjesz istnienie grafików
>> i produkowanych przez nich plików graficznych :-)
>
> Chyba coś nie na temat albo nie nadążam.

Takie rzeczy jak kolory, to się ustala z klientem na projektach
graficznych, a nie "dzielnie sprawdza", czy kolor będzie pasował
wpisując randomowe heksy w kodzie i sprawdzając "czy już 
estetycznie"

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

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

[...]

>> 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?
>
> Eeee... Co znaczy "ma powiększony sam tekst" albo "używa innego fontu"? 
> Użytkownik nie grzebie po CSS.

W przeglądarkach można ustawić zarówno minimalną wielkość fontów (wszelkie
css będą w tym zakresie ignorowane), można nadpisywać "własne" fonty jak
również istnieje funkcjonalność "Zoom Text Only". Czasami są to funkcje
wbudowane, czasami dostępne jako extension. Nie trzeba grzebać po CSS.

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

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

[...]

> Zgoda, ale korzyści z tego też nie mam. Temat jest podobny do ładowania 
> bibliotek jQuery w miejscu gdzie wystarczy jedna linijka kodu w czystym 
> JS. Da się, ale po co?

To może ustalmy o jakiej skali projektów piszesz.

Jak Ty piszesz projekty typu "dwie strony statyczne, trzy obrazki, a jak
się tu kliknie o, to się pojawi napis", to nie pakuj się w framework / edytor / cokolwiek 
który jest przeznaczony do pisania rozbudowanych aplikacji.

I nie oczekuj od tych narzędzi tych samych funkcjonalności.
I o ile "zasady" i narzędzia użyte do pisania dużych projektów można 
przenieść do małych, chociaż jak zauważyłeś niesię to za sobą pewien
narzut, o tyle w drugą stronę już tak nie przejdzie, więc to co 
próbujesz przecisnąć po prostu w tego typu narzędziach nie istnieje,
bo jest niepotrzebne i tworzy więcej problemów niż rozwiązuje.

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

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

W dniu 2018-12-18 o 08:04, Wojciech Bancer pisze:
> 
> To może ustalmy o jakiej skali projektów piszesz.

Każdej skali. Może z wyjątkiem skali FB czy Google. Mam w swojej 
kolekcji zarówno bardzo małe serwisy jak i zaawansowane sklepy (na 
własnym frameworku, którego porzucam) czy też znane międzynarodowe firmy 
o dużej oglądalności wymagające wydajnego CMS. Statycznych stron nie tworzę.

Nie wiem czy moja odpowiedź coś zmienia.

-- 
Pozdrawiam,
Marek

W dniu 2018-12-18 o 07:54, Wojciech Bancer pisze:

> Takie rzeczy jak kolory, to się ustala z klientem na projektach
> graficznych, a nie "dzielnie sprawdza", 

Idealista! Nie pamiętam czy chociaż raz ustalenia nie zostały 
zmodyfikowane w trakcie życia projektu :-D

Grafikiem sam jestem więc mniej więcej wiem czym jest kolor i współpraca 
z klientem. Nie sprowadzaj tematu do dyskusji na poziomie licealisty, 
który kupił sobie podręcznik HTML.

-- 
Pozdrawiam,
Marek

W dniu 2018-12-18 o 07:59, Wojciech Bancer pisze:

> W przeglądarkach można ustawić zarówno minimalną wielkość fontów (wszelkie
> css będą w tym zakresie ignorowane), można nadpisywać "własne" fonty jak
> również istnieje funkcjonalność "Zoom Text Only". Czasami są to funkcje
> wbudowane, czasami dostępne jako extension. Nie trzeba grzebać po CSS.

Jasne, można też wyłączyć JS, odciąć zasilanie od budynku. Co ciekawe 
można też wcisnąć F12 i pozmieniać kod strony, a nawet od zera ją 
napisać w ten sposób. Czy to wszystko uwzględniasz w swoich projektach?

Jeśli tak, to chyba tylko projekt "hello world" z kilkoma liniami HTML 
jest w stanie przetrwać próbę. Choć i to hello world oglądacz może 
zmienić i co wtedy?

-- 
Pozdrawiam,
Marek

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

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

[...]

>> W przeglądarkach można ustawić zarówno minimalną wielkość fontów (wszelkie
>> css będą w tym zakresie ignorowane), można nadpisywać "własne" fonty jak
>> również istnieje funkcjonalność "Zoom Text Only". Czasami są to funkcje
>> wbudowane, czasami dostępne jako extension. Nie trzeba grzebać po CSS.
>
> Jasne, można też wyłączyć JS, odciąć zasilanie od budynku. Co ciekawe 
> można też wcisnąć F12 i pozmieniać kod strony, a nawet od zera ją 
> napisać w ten sposób. Czy to wszystko uwzględniasz w swoich projektach?

Ty się nabijasz, a przypadkiem nabijasz się personalnie ze mnie, jako
z osoby niepełnosprawnej z silną dysfunkcją wzroku, która tego typu 
narzędzia używa w praktyce by móc cokolwiek przeczytać.

O WCAG to pewnie nie słyszałeś w ogóle.

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

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

W dniu 2018-12-18 o 22:19, Wojciech Bancer pisze:

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

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

-- 
Pozdrawiam,
Marek

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

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

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

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

Dnia Mon, 17 Dec 2018 23:05:17 +0100, Marek S napisał(a):

>> Chodzi mi o to, że z taką konstrukcją projektu nie da sie efektywnie
>> pracować bez konkretnego edytora z konkretnym zestawem ustawień. A to nie
>> powinno mieć najmniejszego znaczenia dla kodu.
> 
> Tak, zrozumiałem i odpowiedziałem (poniżej), że z tym nierzadko są 
> kłopoty bo edytory dorzucają od siebie wstawki albo niezrozumiałe dla 
> innych edytorów (to pikuś) albo wręcz powodujące, że kod jest 
> nieczytelny i bez dostosowania plików nie da się z nimi pracować.

Nie, chodzi mi o to, że bez tego narzędzia inny programista podetnie sobie
żyły próbując zmieniać jedną rzecz w 50 plikach.

> ...albo właśnie wpadłem na inny pomysł. W już tym generycznym projekcie 
> zwyczajnie umieszczę wstawki języka blade. Wtedy modyfikacje w postaci 
> np. "wstaw kolumnę do tabeli" będą poprawnie się wykonywały - o ile w 
> PHPStorm da się wstawiać kolumnę. Tego jeszcze nie udało mi się 
> namierzyć. A przy tabelach to ułatwia sprawę.

Robisz akrobacje, by na siłę dopasować narzędzie do trybu pracy z
poprzedniej epoki. To nie zadziała. Albo będzie kuleć.

>> Kursor na własność i Ctrl + Q.
> 
> To już próbowałem. Nie działa.
> https://drive.google.com/file/d/19I0G4n1E1IosnkWpMhrb414CbeKUnci9/view?usp=sharing
> 
> Ctrl + P też nie.

No fakt, nie pokazuje aż tak szczegółowo. Ale tego akurat da się łatwo
nauczyć.

> Ale to jest konwerter kolorów a nie kolor picker. Właśnie póki co 
> najpierw ustalam kolor kolor pickerem a potem konwertuję bo color picker 
> chyba nie potrafi zapisywać w żądanym formacie.

A po co Ci notacja rgb()? Nigdy w życiu nie miałem potrzeby jej użyć, co
najwyżej rgba() z uwagi na przezroczystość. A nawet wtedy korzystam z
ułatwień SCSS, który pozwala na zapis rgba(#xxyyzz, 0.1).

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

W dniu 2018-12-26 o 18:02, Borys Pogoreło pisze:

> Nie, chodzi mi o to, że bez tego narzędzia inny programista podetnie sobie
> żyły próbując zmieniać jedną rzecz w 50 plikach.

Ale po co ma zmieniać w 50 miejscach? Wystarczy, że przerwie automatykę 
aktualizacji edytując jeden z tych 50 plików ręcznie skazując tym samym 
programistę #1 na utratę warsztatu pracy.

Przecież DW z tym narzędziem nie zmienia zasady działania frameworków! 
Zawsze wygenerowane pliki muszą być zgodne z danym frameworkiem. A 
Framework przewiduje iż np. fragment jakiegoś jednego pliku HTML jest 
stopką drugiego i 50-tego. Różnica polega tylko na tym, że zamiast 
podawać frameworkowi wycięty z kontekstu fragment HTML, podajemy 
kompletny plik HTML z zaznaczonym (np. w blade) elementami jakie mają 
być wykorzystane w innym miejscu. Zawsze będą to pełnowartościowe pliki. 
I tylko to się zmienia, co dramatycznie usprawnia pracę webdesignerów. 
Mogą oni dzięki temu nanosić zmiany bezpośrednio do projektu bez 
angażowania programistów.

>> To już próbowałem. Nie działa.
>> https://drive.google.com/file/d/19I0G4n1E1IosnkWpMhrb414CbeKUnci9/view?usp=sharing
>>
>> Ctrl + P też nie.
> 
> No fakt, nie pokazuje aż tak szczegółowo. Ale tego akurat da się łatwo
> nauczyć.

Nie rozumiem? Nauczyć kogo i czego? Nauczyć PHPStorm pokazywania jakie 
atrybuty CSS dany tag HTMLowy odziedziczył, po jakich selektorach i 
jakie z tych atrybutów zostały nadpisane przez inne selektory? Jak tego 
dokonać?

> A po co Ci notacja rgb()? Nigdy w życiu nie miałem potrzeby jej użyć, co
> najwyżej rgba() z uwagi na przezroczystość. A nawet wtedy korzystam z
> ułatwień SCSS, który pozwala na zapis rgba(#xxyyzz, 0.1).

Nie tylko rgb lecz i hsb. A po co? Np. niedawno robiłem w SVG edytor 
kolorów. Nie da się w RGB podnieść jasność bez zmiany koloru bez 
stosowania algorytmów przeliczających. Po co je robić  skoro mamy 
natywną obsługę w JS/DOM?

-- 
Pozdrawiam,
Marek

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

Dnia Wed, 26 Dec 2018 21:14:17 +0100, Marek S napisał(a):

> Ale po co ma zmieniać w 50 miejscach? Wystarczy, że przerwie automatykę 
> aktualizacji edytując jeden z tych 50 plików ręcznie skazując tym samym 
> programistę #1 na utratę warsztatu pracy.

O widzisz, sam zauważyłeś jedną z największych wad tego podejścia.

> I tylko to się zmienia, co dramatycznie usprawnia pracę webdesignerów. 
> Mogą oni dzięki temu nanosić zmiany bezpośrednio do projektu bez 
> angażowania programistów.

Ale nikt im tego nie broni. Trzeba im tylko przygotować środowisko do tego,
o czym już pisałem.

> Nie rozumiem? Nauczyć kogo i czego? Nauczyć PHPStorm pokazywania jakie 
> atrybuty CSS dany tag HTMLowy odziedziczył, po jakich selektorach i 
> jakie z tych atrybutów zostały nadpisane przez inne selektory? Jak tego 
> dokonać?

Nie, nauczyć się kolejności wartości box-shadow.

A efektywne wartości CSS sprawdzasz w przeglądarce, bo to silnik
renderujący się tym zajmuje, nie IDE.

> Nie tylko rgb lecz i hsb. A po co? Np. niedawno robiłem w SVG edytor 
> kolorów. 

Czego brakowało w setce istniejących?

> Nie da się w RGB podnieść jasność bez zmiany koloru bez stosowania
> algorytmów przeliczających. Po co je robić  skoro mamy natywną obsługę w
> JS/DOM?

To jest ekstremalnie niszowy przypadek, z którym zetknie się może jeden na
stu, jeśli nie mniej. Także poza tworzeniem edytora kolorów po co Ci
notacja rgb()?

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

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

W dniu 2018-12-26 o 23:32, Borys Pogoreło pisze:

>> Nie rozumiem? Nauczyć kogo i czego? Nauczyć PHPStorm pokazywania jakie
>> atrybuty CSS dany tag HTMLowy odziedziczył, po jakich selektorach i
>> jakie z tych atrybutów zostały nadpisane przez inne selektory? Jak tego
>> dokonać?
> 
> Nie, nauczyć się kolejności wartości box-shadow.
> 
> A efektywne wartości CSS sprawdzasz w przeglądarce, bo to silnik
> renderujący się tym zajmuje, nie IDE.

Hmmm... no to bieda. :-( Trochę to wydłuża development bo zamiast 
widzieć na bieżąco co dany tag dziedziczy, czy coś nie przesłoni 
selektora jaki sobie wymyślamy w danej chwili, to przesuwamy to do fazy 
testów. No ale ok, może tak jest bardziej trendy i trzeba się zwyczajnie 
przyzwyczaić.

>> Nie tylko rgb lecz i hsb. A po co? Np. niedawno robiłem w SVG edytor
>> kolorów.
> 
> Czego brakowało w setce istniejących?

Tego, że nie realizowały edycji zdjęć / dokumentów tak jak ja tego 
oczekiwałem. Edytor kolorów był tylko jedną z wielu funkcji.

> To jest ekstremalnie niszowy przypadek, z którym zetknie się może jeden na
> stu, jeśli nie mniej. Także poza tworzeniem edytora kolorów po co Ci
> notacja rgb()?
> 

Hmmm... nie wiem jakie są statystyki lecz głównie żyję z niszowych 
projektów takich jak np. system integrujący współpracę wydawnictw w 
zakresie grafiki a wcześniej automatyzacja obsługi finansowej, w tym 
zarządzanie call center, dedykowany CRM itp. Praktycznie non-stop w 
takich rzeczach grzebię.

-- 
Pozdrawiam,
Marek

Dnia Fri, 28 Dec 2018 23:20:38 +0100, Marek S napisał(a):

> Hmmm... no to bieda. :-( Trochę to wydłuża development bo zamiast 
> widzieć na bieżąco co dany tag dziedziczy, czy coś nie przesłoni 
> selektora jaki sobie wymyślamy w danej chwili, to przesuwamy to do fazy 
> testów. No ale ok, może tak jest bardziej trendy i trzeba się zwyczajnie 
> przyzwyczaić.

A nie ogarniasz tego po prostu w głowie? Jeśli nie przeginasz ze strukturą
DOM, to wcale nie jest trudno sobie wyobrazić efekt końcowy.

I wracamy tym samym też do tematu browsersync.

>> Czego brakowało w setce istniejących?
> 
> Tego, że nie realizowały edycji zdjęć / dokumentów tak jak ja tego 
> oczekiwałem. Edytor kolorów był tylko jedną z wielu funkcji.

Ok, to się zdarza.

> Hmmm... nie wiem jakie są statystyki lecz głównie żyję z niszowych 
> projektów takich jak np. system integrujący współpracę wydawnictw w 
> zakresie grafiki a wcześniej automatyzacja obsługi finansowej, w tym 
> zarządzanie call center, dedykowany CRM itp. Praktycznie non-stop w 
> takich rzeczach grzebię.

Ja też mam niszowe projekty, ale to nadal nie wyjaśnia potrzeby użycia
akurat notacji rgb().

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

W dniu 2018-12-29 o 01:33, Borys Pogoreło pisze:

> A nie ogarniasz tego po prostu w głowie? Jeśli nie przeginasz ze strukturą
> DOM, to wcale nie jest trudno sobie wyobrazić efekt końcowy.

Oczywiście, że nie. Gdybym sam tworzył środowisko, to ogarniałbym temat. 
Jakiś czas temu tworzyłem aplikacje dla X czy Y lecz obecnie muszę się 
odnaleźć w zakupionych produktach, które są rozwijane przez grupę.

> Ja też mam niszowe projekty, ale to nadal nie wyjaśnia potrzeby użycia
> akurat notacji rgb().

Bo to kwestia tematyki. Jeśli tworzysz np. programy księgowe to nie ma 
to znaczenia. Ja siedzę w grafice i zanosi się, ze to praca na całe 
lata. Zresztą grafika, fotografia, to moje natywne środowisko.

-- 
Pozdrawiam,
Marek