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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#15897

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

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

#15905

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

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

#15906

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

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

#15909

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

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

#15910

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

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

#15920

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

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

#15962

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

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

#15963

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

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

#15969

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

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

#15989

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

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

#15993

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

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

#15994

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

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

#15900

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

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

#15907

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

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

#15911

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

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

#15921

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

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

#15924

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

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

#15929

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

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

#15935

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

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

#15939

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

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

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

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

csiph-web