Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

 
Reply to this topicStart new topic
> [CMS] Struktura i rozmieszczenie zawartości, Współpraca, wydajność, niezależność...
Struktura zawartości
Czy potrzebujesz wstawiać elementy różnego typu (np. pliki, newsy, linki, obrazy, artykuły) do 1 kategorii?
Tak - koniecznie [ 6 ] ** [42.86%]
Przydałoby się... [ 1 ] ** [7.14%]
Nie mam potrzeby [ 1 ] ** [7.14%]
Nie - to tylko spowoduje bałagan [ 6 ] ** [42.86%]
Czy każdy element (różnych typów) powinien mieć podstawowe dane w 1 tabeli (np. items)?
Tak - zapewni to większą współpracę [ 6 ] ** [42.86%]
Nie - każdy typ ma swoje cechy [ 5 ] ** [35.71%]
Nie wiem / inna odp. [ 3 ] ** [21.43%]
Suma głosów: 14
Goście nie mogą głosować 
WebCM
post
Post #1





Grupa: Zarejestrowani
Postów: 375
Pomógł: 20
Dołączył: 28.07.2006

Ostrzeżenie: (0%)
-----


Temat dotyczy rozmieszczenia danych w bazie SQL. Chodzi o to, aby umożliwić jak największą współpracę i elastyczność poszczególnych elementów (artów, plików, newsów...), a za razem zachować niezależność i wydajność (np. nie ładować zbyt wielu plików przy odczycie z powodu różnic). Wypowiedzcie się na ten temat.

Teraz mam taką strukturę: artykuły, pliki, obrazy, linki i nowości są przechowywane w swoich tabelach, np. "arts", "files"... Można je przypisać do 1 kategorii o ustalonym typie (!). Nie można więc zamieścić np. linków w katalogu przeznaczonym dla artykułów. Przykład adresów: /file/50, /art/20

Każdy typ kategorii ma też oddzielny plik, wyświetlający listę znajdujących się w niej elementów. Domyślnie w szablonach dla artykułów jest to tylko tabela, zaś dla obrazów - widok typowy dla galerii.

Inne spojrzenie
Taka zmiana nie każdemu może odpowiadać, gdyż wiążą się z nią zarówno: większa elastyczność oraz ograniczenia. Podstawowe dane o wszystkich elementach znalazłyby się w 1 tabeli, np. "items" z polami:
- tytuł
- kategoria, do której należy
- opis
- autor / dodał
- ocena
- dostęp (1 - włączony, 0 - wyłączony)
- opcje [być może]
- ilość komentarzy [prawdopodobnie]

Spowoduje to zwiększenie elastyczności. Stanie się możliwe umieszczenie w 1 kategorii elementów różnego typu, np. plików, grafiki... Wszystkie typy będą zawierać powyższe dane, a więc komentarze i oceny zagoszczą nawet pod informacjami o odnośniku (na osobnej stronie). W ustawieniach kategorii pojawi się opcja: "widok elementów", np. "miniatury" (jak w galerii), "lista". Adresy mogą przybrać formę jak obecnie lub: /item/50, /view/50

Operacje typu: sortowanie wg oceny, pokazywanie / liczenie ilości komentarzy... prawdopodobnie staną się łatwiejsze i mniej skomplikowane. Zmiana niesie za sobą również ograniczenia. Zmniejszy się niezależność każdego typu kategorii na rzecz większej integracji i spójności. Generalnie wyświetlanie dodatkowych informacji o plikach na liście (np. jak w PHP-Fusion) będzie niemożliwe, chyba że pozwoli na to specjalny dla plików widok (wstawienie np. linku może spowodować problem!).

(*) Pozostaje pytanie, czy jest sens tworzyć dodatkową tabelę dla linków, aby trzymać tam jedynie adres URL, ilość kliknięć i opcje (otwórz w nowym oknie).

Ten post edytował WebCM 21.05.2008, 15:50:35
Go to the top of the page
+Quote Post
cbagov
post
Post #2





Grupa: Zarejestrowani
Postów: 181
Pomógł: 18
Dołączył: 19.04.2008

Ostrzeżenie: (10%)
X----


Wlasnie tak mam to zorganizowane, dodawany element - nie wazne co - zawsze ma autora, tytul, date itp. Dopiero na pozniejszym etapie za pomoca roznego rodzaju korelacji widoku z kategoriami wychodzi w wyniku wizualizacja adekwatna dla konkretnego typu ELEMENTU.
Co to daje ?
1 glowny interface do wszystkiego + mozliwosc definiowania widokow/list cech, dla dowolnych nowych typow elementow oraz ich edycji - w formie jaka mozna nazwac 'plugin'.
Go to the top of the page
+Quote Post
nevt
post
Post #3





Grupa: Przyjaciele php.pl
Postów: 1 595
Pomógł: 282
Dołączył: 24.09.2007
Skąd: Reda, Pomorskie.

Ostrzeżenie: (0%)
-----


ja podszedłem do zagadnienia w ten sposób:

1. mam zbiorczy element - powiedzmy artykuł. artykuł ma autora, datę utworzenia, datę modyfikacji, ocenę, wagę, status itp.
2. artykuł budowany jest z elementów pierwotnych: pliki, obrazy, paragrafy (tekst), tabele itp.
3. elementy pierwotne trzymam w indywidulanych tabelach / katalogach dopasowanych do przechowywanych treści.
4. artukuły przydzielam do kategorii, czyli czy to news, porada, komentarz, ocena, art, kod - ten sam artykuł może być dowiązany do wielu kategorii - dzięki temu opis produktu z katalogu może być jednocześnie top promocją bez powielania wpisów...
5. widoki buduję na bazie kategorii
Go to the top of the page
+Quote Post
jarek_bolo
post
Post #4





Grupa: Zarejestrowani
Postów: 149
Pomógł: 12
Dołączył: 3.03.2008
Skąd: łódzkie

Ostrzeżenie: (0%)
-----


Niejaki SasQ na grupie pl.comp.lang.php dał Ci już linka do bardzo wartościowego Bloga sześciu Geeków z Sioux Falls, South Dakota, USA (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)
Ja również podam to co on i dwa artykuły więcej, bo cały dzień siedzę i czytam od deski do deski tego bloga.
Jest tam super wyłożona problematyka CMSów. Polecam dogłębnie przestudiować tego bloga. Jest kategoria o CMSach. Postów jest sporo i niektóre już są stare, ale myślę, że wciąż aktualne.
Autor bardzo wychwala architecture eZ Publish.

Co do Twoich rozważań to przeczytaj sobie w kolejności jak podaje:
1) http://www.gadgetopia.com/post/259 (Open and Closed Content Management)
2) http://www.gadgetopia.com/post/4203 (The Envelope Pattern of Content Management)
3) http://www.gadgetopia.com/post/4237 (The Content Tree)

Ten post edytował jarek_bolo 23.05.2008, 13:07:09
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
2 Użytkowników czyta ten temat (2 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 



RSS Aktualny czas: 24.08.2025 - 13:19