wtorek, 14 lutego 2023

Jak kiedyś tworzyło się strony internetowe. HTML 4 i CSS 2 - grafika, ramy itd.

 Postanowiłem napisać temat o tym, jak kiedyś tworzyło się strony internetowe. Co prawda i tu zaznaczę, że wszystkiego i tak nie napiszę, więc, jeżeli czegoś zabraknie, to nie będzie oznaczać, że nie wiedziałem. Zapraszam.

Od wielu lat mamy HTML5 i CSS3. Dziś tworzenie stron w nowej wersji HTML i CSS, bardzo ułatwia nam pracę oraz pojawiło się wiele atrybutów, które nawet poprawiają nie tylko wygląd strony, ale też dają niesamowite efekty wizualne. Ale wróćmy wstecz o ponad dekadę, przypomnę jak kiedyś tworzyło się strony internetowe.

HTML4 i xml - wersje kodowania

W HTML 4 nie było możliwości dodania krótkiej linijki kodu DOCTYPE, jak ma to teraz. Kiedyś trzeba było określić xml version="...." tak było w przypadku XHTML, a jeżeli chodzi o sam HTML 4, były takie linie kodu, które były wykorzystywane w zależności, jak ma strona wyglądać. Poniżej daję trzy linie kodu DOCTYPE:

Strict

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

Transitional

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

Frameset

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">

Każda z tych linijek kodu, która zaczynała szkielet strony, dawała swoje właściwości. Jeżeli chodzi o tworzenie stron z tzw. pływającymi ramkami, to można było we wszystkich kodowaniach DOCTYPE HMTL 4 tworzyć, ale były różne efekty.

Dobrze linie kodu wersji HTML4 mamy za sobą, ale jak tworzyło się strony? Jak zaczynało się, już napisałem, ale jak tworzyło się strony?

Strony z pływającymi ramkami

Takie strony różnie wyglądały i sam tworzyłem. Niby fajnie to wyglądało, ale miało jedną wadę. Nie można było w każdej ramce umieścić zbyt dużo tekstu. Przykładowo. Chcemy stronę z menu po lewej stronie, a po prawej tekst strony. Czyli w ramce <iframe strona 1> musi być strona w menu z ustaloną wcześniej szerokością. Natomiast, w ramce drugiej <iframe strona 2> tekst strony. Dodam, że do każdego atrybutu iframe dodawało się ścieżkę stron, czyli <iframe src="strona.html"> itd. Dodatkowo, pojawiały się suwaki, co nie każdy chciał, ale jak było długie menu, to musiał być suwak przewijania.

Strony oparte na tabelach niż na blokach div

Sam tworzyłem strony oparte na tabelach niż na div. Lecz w HTML 4 i CSS2 też tworzyło się strony na blokach div a nie na samych tabelach, ale tworzyło się. Dziś, na tabelach nie tworzy się stron, ponieważ tabele służą do prezentowania danych z baz danych. Są strony zwane CMS, które są oparte na tabelach. Takim CMS-em jest dobrze znany PHP-Fusion. Sam korzystałem, ale później mi się znudził.

Strony we flash'u

Każdy widział stronę i to nie jedną zrobioną we flashu. Animacje, wysuwane menu a do tego jeszcze był wykorzystywany (inaczej by strony nie działały), język ActionScript 2.0, później 3.0. I takim programem dość popularnym był Macromedia Flash. Były jeszcze reklamy tworzone w tym języku, co wymagało od użytkownika instalacji flash player. Nie każda przeglądarka wymagała instalacji flash playera, Opera miała już wbudowany taki player. Można dziś sobie używać flash  playera, ale jest odradzany! To zależy od użytkownika, czy chce to mieć.

Grafika - zaokrąglone narożniki

Kiedyś tworząc stronę, cięło się grafikę w photoshop na małe części. A cięło się po to, aby strona szybciej ładowała się niż cała duża grafika. Dziś (nie jestem pewny), pewnie stosuje się, ale mając na uwadze nową wersję HTML5 i CSS3, i możliwości, strony lepiej wyglądają niż kiedyś. Poza cięciem grafiki, był problem z zaokrągleniem narożników. Aby zaokrąglić rogi, trzeba było ponownie pociąć grafikę i napisać tak styl w CSS, aby wszystko dobrze pasowało. Kiedy pojawił się CSS3, to aby zaokrąglić narożniki, nie trzeba ciąć grafiki, wystarczy wpisać w dany blok div, p, header itd., linijkę border-radius: i tu ustalamy wartość w pikselach. To dało duże ułatwienie. 

Dodatkowo, przy tworzeniu stron, każdy program bez względu, czy to płatny, czy darmowy, miał szablon wersji, czyli Strict, Transitional, iframe. I jaki wybrało się, taki kod wygenerował ze znacznikami  meta.

I tym samym kończę podróż, właściwie krótką podróż po tworzeniu stron przed rokiem 2010.

poniedziałek, 6 czerwca 2022

Paginacja na stronach internetowych. Czy warto jeszcze stosować paginację na stronach internetowych?

 Dzisiejszy temat będzie dotyczył paginacji na stronach internetowych. Napiszę, czym jest paginacja i czy warto w dzisiejszych czasach, w roku 2022 jeszcze stosować paginację. Zapraszam.

Czym jest paginacja?

Paginacja na stronie polega na dzieleniu wszystkich wpisów w bazie na strony, które są małymi stronami, i mają ustawione ilość wpisów na stronę. Paginacja jest  dobrze znana programistom piszącym w języku PHP, ale i nie tylko w tym języku, lecz przeważnie. Typowa paginacja, jaką stosowano i nadal stosuje się, wygląda w następujący sposób:

<< < 1,2,3,4,5.... 30,31,32,33,34,35...60,61,62,63,64,65 > >>

Powyższy przykład pokazuje typową paginację. Pisząc typowo, nie oznacza, że taka paginacja jest zła. Również możemy spotkać inną paginację, podobnej do powyższego przykładu, co pokazuję niżej.

 << < 1,2,3,4,5,6,7...40,41,42,43,44,45...70,71,72,73,74 > >> 5 /200

 To jest ta sama paginacja, tyle, że podświetla aktualną, bieżącą stronę na której jesteśmy oraz na końcu wyświetla również bieżącą stronę z liczby wszystkich stron, jakie są w bazie. Taka paginacja jest dobra, ale z czasem może być problematyczna. Gdyż do samych wpisów np:artykułów na stronie, prezentacji filmów może być dobra, to lepszą i od paru lat stosowaną paginacją jest uproszczenie, która ma tylko strzałki nawigacji, aktualny numer strony oraz ilość wszystkich stron, co pokazuję poniżej.

< << 1/200 > >>

Taka paginacja jest bardziej czytelna, która ma nawigację w postaci strzałek i co ważne, nie wyświetla już wszystkich podstron z kropkami. Paginacja z wyświetlaniem stron i kropek jest starą paginacją od której właściwie się odchodzi, co nie znaczy, że nie stosuje się lub nie warto stosować. Nie, można stosować i taka paginacja nie oznacza, że jest zła. Po prostu jest stara, i tyle.

Czy warto stosować paginację na stronach?

Odpowiadając na to pytanie, można zadać inne, czy warto mieć dowód osobisty? Skoro, widać naszą twarz, to po co dowód osobisty. Odpowiadam, tak warto stosować paginację bez względu jak miałaby wyglądać, byle, aby była czytelna i miała nawigację po stronach, po to, aby można było przejść do danej podstrony. Wyobraź sobie setek artykułów na stronie bez paginacji. Jakby to wyglądało? Przykładowo masz 100 wpisów z artykułami, to musisz przewijać i przewijać suwakiem, co nie jest wygodne, dlatego stosuje się paginację. 

Również stosuje się oprócz pokazanej paginacji wyżej, ładowanie wpisów po skrollowaniu suwaka myszką. Ta metoda też jest stosowana i dobrze wypada. 

Na zakończenie. Powyższe przykłady dałem z przecinkami, ale paginacja na stronach nie ma przecinków! Dlatego nie pisz, że nie stosuje się paginacji z przecinkami.

poniedziałek, 24 stycznia 2022

Strona internetowa bez przeładowania strony. Czy warto użyć AJAX lub JQuery a może JS + framework JS?

 Dzisiejszy temat będzie dotyczył tematu tworzenia stron, które odświeżają swoje dane przeładowując całą stronę, czy też pewne części strony bez przeładowania strony, czy jak to się mówi, bez odświeżania. Zapraszam.

Każdy kto tworzył strony internetowe, to na pewno spotkał się z problemem (zależy jak na to patrzeć) odświeżania strony lub prezentowania danych po dodaniu bez odświeżania strony. I jest na ten temat dużo artykułów. Jedni piszą o zastosowanie AJAX lub biblioteki JQuery z funkcją ajax lub o zastosowanie języka JS z danym frameworkiem. Tu są zdania podzielone.

Zadajmy sobie pytanie. Czy potrzebujemy stronę, która będzie pokazywać dane bez przeładowania strony? Odpowiedź nie jest jednoznaczna, ponieważ zależy od tego, jaka to ma być strona. Czy to na być duży portal informacyjny, portal społecznościowy, czy zwykła strona. Bez względu na to, jaka nie byłaby strona, nie zawsze stosuje się na stronach funkcje, które pokazują informacje bez odświeżania strony. 

Tak naprawdę zależy od tego, jak strona została zrobiona i czy nie jest ciężka. Czy ładuje się szybko, czy wolno. Jak jest ciężka, a na stronie jest dużo grafik, i jeszcze reklamy, to taka strona na pewno będzie wolno ładować się a całe odświeżanie strony może tyle samo trwać, co samo ładowanie strony. Takie działanie strony może irytować użytkownika, ponieważ raz, że doda komentarz, i jak kliknie dodaj, to zamiast dodać szybko komentarz, to będzie przeładowana cała strona, która załaduje się ok 3-6 sekund, w zależności, jaka to jest strona, i od naszego łącza internetowego!

Nie ma co ukrywać, że dzisiejsze strony nie zawsze działają dobrze, i tu mam na myśli prezentowanie danych, wyników bez odświeżania strony. Tak samo, nie każda strona prezentuje swoje dane bez przeładowania strony, przecież to tylko bajer, ale jaki przydatny, i funkcjonalny bajer:) No dobra, ale czy warto zawracać sobie głowę samym AJAXEM lub JQuery, która ma funkcję ajax? Jak znasz dobrze JS i framework, który daje efekt prezentowania danych z bazy bez odświeżania strony, to trzymaj się tego, i zapomnij  AJAX i o JQuery! Jak już, to wolę użyć JQuery z funkcją ajax. 

Jeżeli prezentujesz duże ilości danych na stronie a zakładasz, że będzie korzystać duża ilość użytkowników, to najlepiej użyć na stronie funkcję, która nie tylko pokaże dane bez przeładowania strony, ale też samo dodanie danych bez przeładowania strony! I to jest bardzo ważne, jak na dzisiejsze czasy, ale czy musisz? Wcale nie, to zależy od twórcy, jak i samej strony. 

Popularną funkcją na stronach informacyjnych jest to, że zmienia się tylko ta część strony, która jest bez przerwy aktualizowana, niż aktualizowanie danych z odświeżaniem strony. Zastanów się, ile razy strona musiałaby aktualizować się, jeżeli duże grono osób dodawało by dane?

To tyle w tym temacie:) A jak Ty zrobisz, to zależy od Ciebie. 

I na koniec. Czy brak na stronie internetowej funkcji  dodawania i prezentowania danych bez odświeżania, jest złą praktyką programisty,  i czy jest to duży minus? Raczej nie, lecz strony, na których są  prezentowane dane bez przeładowania strony lepiej działają.

czwartek, 10 czerwca 2021

MySQLi vs.PDO. Które połączenie jest lepsze?

 Temat będzie dotyczył połączeń MySQLi i PDO, które do dziś są stosowane w aplikacjach przez programistów PHP. Napiszę, które jest lepsze, i które warto stosować. I na koniec, rozwieję jedną totalną bzdurę, którą można przeczytać na forach dotyczących PDO i MySQLi.

Kiedyś, kiedy pisano aplikację w PHP w połączeniu z bazą danych, to stosowano się przeważnie mysql_connect i mysql_query. Dziś są to stare i wyłączone funkcje połączeń z bazą, jak i zapytań do bazy danych. I po mysql_connect, w PHP powstało połaczenie new mysqli i jeszcze później PDO.

No właśnie, to które połączenie jest lepsze, mysqli czy PDO?

Stosując new mysqli jesteśmy skazani tylko na jedną bazę danych, a taką jest baza MySQL. Czy to wada, czy zaleta? To zależy, co tworzymy, i dla kogo. Jeżeli nasza aplikacja np: CMS ma być tylko instalowany na jednej bazie danych, to można użyć połączenia mysqli. Jednak w dzisiejszych czasach, liczy się możliwość instalacji na wielu platformach serwerowych, niż tylko na jednej. Wiem, platforma kojarzyć może się z systemem operacyjnym a nie bazą danych, ale tak to nazwałem.Dlatego, stosując połączenie mysqli a dokładniej new mysqli, nie zainstalujemy, nie wdrożymy naszej aplikacji na innej bazie danych! Można zapomnieć o SQL Server, Oracle, Postgree SQL, itd. Dlatego, ważna jest możliwość zainstalowania na wielu serwerach bazy danych, niż tylko na jednej. 

Stosując PDO, możemy napisaną aplikację wdrożyć/użyć na każdej bazie danych, a nie tylko jednej. I to jest przewaga PDO nad mysqli. Jeżeli chodzi o samo stosowanie mysqli, to nie ma w tym nic złego. Większość hostingów ma obsługę języka PHP, i stosowanie nie jest czymś złym. Jest jedna uwaga, bez względu, czy stosujemy mysqli, czy PDO, warto zwrócić uwagę na wersję PHP. Może tak być, że kolejna wersja PHP, nie będzie obsługiwała mysqli, to tylko kwestia czasu.

Sam jeszcze korzystam z mysqli, i nie uważam, aby w tym coś było złego. A teraz, na koniec rozwieje totalną głupotę.

TOTALNA GŁUPOTA: Każdy myślący/profesjonalny programista PHP nie będzie używał mysqli, tylko PDO

Takiej głupoty jeszcze nie czytałem. Można stworzyć bardzo dobrą aplikację np: CMS, forum itd., stosując połączenie mysqli. Tylko, jak wyżej napisałem. Dziś liczy się możliwość instalacji na wielu bazach danych, niż na jednej. Stosując mysqli, jesteśmy ograniczeni/lub nie (zależy od aplikacji), tylko do jednej bazy. Przy PDO, możemy użyć każdej, pod warunkiem, że PDO obsługuję taką bazę danych.

poniedziałek, 30 listopada 2020

Responsive file manager w edytorze CKEditor

W temacie, gdzie pokazywałem implementację KCFinder w edytorach CKeditor i TinyMCE, wspomniałem o alternatywie dla KCFindera, a nim jest właśnie Responsive File Manager! I dziś pokażę, jak zaimplementować w edytorze CKEditor.

Tym razem, nie będę pokazywał jak zaimplementować w CKeditorze i TinyMCE, ponieważ dużej różnicy nie ma, poza wyglądem i funkcjonalnością obu edytorów. Nie będę pokazywał, jak zaimplementować, ponieważ dokładna dokumentacja i to dobra jest na stronie twórców RFM (https://www.responsivefilemanager.com/#documentation-section). Pokażę, jak wygląda i co można zmienić, jeżeli nie będzie nam pasowało domyślne ustawienie. 

Zakładam, że pobrałeś i zaimplementowałeś, tak jak jest na stronie. Jeżeli robiłeś tak jak jest na stronie, a mimo to nie działa. To pokażę, jak zaimplementować. 

Po pierwsze, co jest oczywiste, musisz mieć działający edytor CKEditor. Jak u mnie wygląda układ katalogów? Nic zwyczajnego, nic nie zmieniałem, pobrałem CKEditor i rozpakowałem do katalogu na serwerze Xampp.

katalogi w ckeditorze

Jak widać, jest już pobrany ze strony i przeniesiony katalog responsive file manager, katalog filemanager. Jak wyglądają pliki w katalogu filemanager? Poniżej przedstawiam zrzut.

Teraz trzeba w pliku php, dołączyć, aby zadziałało ładowanie plików przez CKEditor. U mnie jest plik index.php. Trzeba wpisać odpowiednie linijki kodu, jak przedstawiłem na poniższym zdjęciu:

Gdy już to mamy napisane i stworzone katalogi. Przechodzimy do pliku, gdzie config.php, który jest w katalogu config. Tak jak jest na stronie, to samo tu pokażę, ale już z ustawieniami, takimi, aby wszystko działało. Nie będe dawał już zrzutu, ale należy zrobić tak, jak jest u mnie. Uwaga! To są moje ustawienia. Jeżeli masz inaczej, tzn. katalogi są w innej lokalizacji, to musisz zrobić, tak jak to niżej podaję. Ale dając swoją ścieżkę!

Odszukaj linie:

'upload_dir' => '/www/ckeditor3/uploads/',

'current_path' => '../uploads/',,

'thumbs_base_path' => '../thumbs/',

 'thumbs_upload_dir' => '/thumbs/', domyślnie powinno być bez zmian

'mime_extension_rename'    => true, domyślnie powinno być bez zmian

'filePermission' => 0755,

'folderPermission' => 0777,

I to wszystko, zapisujemy i otwieramy stronę z edytorem, wchodzimy lub klikamy na upload plików, i tak oto powinien przedstawiać się wygląd Responsive File Managera:

Jak widać, dużo lepiej prezentuje się, niż KCFinder. Możemy również w pliku config.php, wyłączyć zbędne ikony oraz zmienić język. Ale to już Tobie to pozostawiam:)

Licencja dodatku do edytora, CKFinder, dla jednego użytkownika jest za free. Dla wielu już trzeba płacić. 

Jeżeli nadal nie wiesz, który wybrać, to pobierz CKFinder, i sam zobacz, porównaj. I działaj!

wtorek, 29 września 2020

Zmiana wielkości pola checkbox

Pola checkbox każdy widział, chociażby przy formularzach, gdzie trzeba zaakceptować warunki licencji, regulamin itd.

Temat dość błahy lub banalny, ale może być też przydatny. Chodzi o zmianę wielkości pola checkbox. Można zadać pytanie, po co zwiększać wielkość, skoro jest widoczny? 

Tu trzeba wyjść na przeciw osobom niedowidzącym lub po prostu chcą mieć większe pola.

Generalnie, pola checkbox daje się większe, aby każda osoba widziała i nie miała problemu ze znalezieniem takiego pola. Przykładowo, wypełni formularz i klika na submit Wyślij, ale pojawi się komunikat o zaakceptowaniu regulaminu. I tu może osoba przeoczyć.

Jak zrobić? Jeżeli mamy już formularz z polem, z polami, to wystarczy do pliku css, dodać następujące linijki:

input[type='checkbox']{
    -moz-transform: scale(2);
    transform: 2;
}

Po zapisaniu, pola checkbox będą większe, ale uwaga! Tylko dla przeglądarek Firefox, dlatego jest tylko -moz-transform.

środa, 29 kwietnia 2020

Implementacja KCFinder w edytorach CKEditor i TinyMCE

Na blogu pisałem o edytorach CKEditor i TinyMCE, pokazując zrzuty kodu danego edytora. Czas na zaimplementowanie KCFinder do ładowania mediów np: zdjęć.

KCFinder był pierwszym pluginem do edytora CKEditor. Owszem są inne rozwiązania (lepsze) np:CKFinder, który jest dodatkiem płatnym, choć wersja free umożliwia korzystanie bez opłat tylko dla jednego użytkownika. Są jeszcze inne managery ładowania mediów.
KCFinder można było pobrać ze strony http://kcfinder.sunhater.com/download. Obecnie strona nie istnieje, ale dla przypomnienia, jak wyglądała, to dam wcześniejszy rzut strony, który kiedyś wykonałem, gdy strona działała.

strona Sunhater - KCFinder
I z takiej strony można było pobrać, odpowiednią wersję dla edytora CKEditor lub dla TinyMCE. Obecnie KCFinder można pobrać z tej strony: https://sourceforge.net/projects/kcfinder/
Zacznijmy od tego, jak zaimplementować w edytorach CKEditor i w TinyMCE. Zakładam, że pobrałeś i rozpakowałeś, a następnie przeniosłeś katalog kcfinder w miejsce, gdzie masz już swój edytor na stronie (czyli działa wybrany edytor). 
Jak nie wiesz o czym piszę, to na blogu pisałem o obu wspomnianych edytorach, i jest tam zrzut, gdzie znajduje się katalog kcfinder. 

Implementacja KCFinder w edytorze CKEditor

Wejdź w katalog CKEditor i wybierz config.php. Jeżeli otworzyłeś dowolnym edytorem plik config.php, to teraz wystarczy wkleić (u mnie przepisać!) następujące linijki kodu:


Zapisz i możesz zamknąć, ale jedna uwaga, ten kod musi być w: 
CKEDITOR.editorConfig = function( config ) {
Tu znajdują się linijki kodu, i nie tylko linijki odpowiadające za kcfinder, ale też za inne ustawienia edytora
}
Następnie wejdź w katalog KCFinder i otwórz plik config.php. Dla obu edytorów ustawienia są takie same, dlatego nie będę umieszczał dwa razy tych samych linijek kodu, choć mogą się różnić wg.swoich potrzeb. O to, co musisz zmienić. Patrz na zrzucie.


Domyślnie disabled jest ustawione na TRUE, zmień na FALSE. Dalej, musisz podać ścieżkę, gdzie mają się ładować zdjęcia. Możesz, ale nie musisz, dać nazwę dla okna, w którym będziesz mógł załadować zdjęcie. I tyle! Jak wcześniej napisałem, te ustawienia są takie same dla obu edytorów. 

Implementacja KCFinder w edytorze TinyMCE

Robisz te same kroki, jakie wyżej napisałem przy implementacji KCFinder w CKEditor. W pliku config.php edytora TinyMCE  ustawiasz to co jest wyżej. Natomiast, mając pod uwagę, że TinyMCE jest edytorem JS, wystarczy (zależnie od położenia pliku konfiguracyjnego) w ramach funkcji:

tinymce.init({ 
Wpisać ten oto fragment kodu:


});
Jak widać, jest tylko jedna linijka, która odpowiada za ładowanie pliku, reszta linijek, to dodatkowe ustawienia.  Po zapisaniu powinno teraz działać ładowanie zdjęć do edytora. 

Oprócz  KCFinder i CKFindera jest inne rozszerzenie o nazwie  file manager, niestety też jest płatny.
Dlatego dobrym wyjściem dla KCFinder i CKFinder, alternatywą może być Responsive file manager i można stąd pobrać: https://www.responsivefilemanager.com/ . Sam zaimplementowałem do CKEditora i w porównaniu z KCFinder dużo lepiej wygląda i ma więcej możliwości. Ale to już na osobny temat.