Praca nad coyote 0.9.2-rc1

0

Wreszcie postanowilem wziac sie za siebie, ruszyc cztery litery i zrobic to, co zostalo przewidziane w TODO do wersji 0.9.2-rc1 :)

Poniewaz szykuja sie spore zmiany, ktore troszke potrwaja na CVS zostanie umieszczona nowa galaz, do ktorej bede wrzucal nowe pliki (niestabilne). Na subdomenie i osobnym koncie FTP postawie tez testowa wersje Coyote.

Tak wiec szykuje sie:

a) zmiana systemu dodawania artykulow, mozliwosc edycji artykulu przez kazdego z mozliwoscia cofniecia zmian (do dyskusji)
b) zmiana calego systemu dodawania plikow w serwisie (bardziej rozbudowany formularz dodawania, przepisanie skryptow od nowa)
c) podzial na kategorie w Download/Artykulach (do dyskusji)
d) utworzenie aukcji pracy (dzial "Praca")
e) poprawienie wyszukiwarki na glownej stronie

Szykuje sie sporo zmian, pewnie nie obejdzie sie bez zmiany struktury bazy. Pisze ten watek, aby podyskutowac o zmianach/pomyslach - co dodac, jak rozbudowac mechanizmy Coyote'a... w tym nalezy odpowiedziec na pytanie:

  1. Czy wylaczyc/ograniczyc uzywanie HTML w artykulach?
  2. Czy w artykulach wykorzystywac cos na wzor BBCode? A moze cos na wzor tagow z wikipedii?
  3. Moze utworzyc formularz typu WYSIWYG przy dodawaniu artykulow?

Mialem tez calkiem inna "wizje" dotyczaca rozbudowania serwisu, aby byl bardzie jak wikipedia... Tj. latwe tworzenie stron w serwisie przez kazdego usera, mozliwosc edycji strony glownej przez kazdego usera, dodawanie subkategorii - no calkiem podobnie jak na wikipedii ;) Ale to juz jest rewolucyjna zmiana, sam jeszcze do konca "nie widze" jak to mialoby wygladac.

Nalezy tez odpowiedziec na pytanie o rozwoj Coyote... ja do tej pory bylem za tym, aby Coyote byl systemem ogolnegoprzeznaczenia - jak setki innych CMS'ow... teraz juz nie jestem taki pewien, nie wiem czy rozwijac Coyote pod katem serwisu programistyczno-informatycznego, pod katem 4programmers.net, nie zwracajac uwagi na to, ze nie bedzie typowym CMS'em jak Mambo ;) I tak nie ma szans zwojowac rynku, istnieja setki lepszych CMS'ow (jak Mambo) czy kompletnych kombajnow jak ezPublish...

0

moze nie jestem zbyt kompetentny, ale sprobuje.

Do czego sluzy html w artykułach? W zasadzie jak ktos nie zna się za bardzo na tym, to moze zrobic sporo zamieszania.
I jeszcze jedno, dobrym rozwiazaniem bylo by moderowanie dzialow. Tak zeby artykuł przez publikacja czekał na akceptacje moda.

Pozdrawiam..

0

To drugie kloci sie z pomyslem, aby kazdy mogl poprawiac artykul wzorem Wikipedii.

0
Adam Boduch napisał(a)

To drugie kloci sie z pomyslem, aby kazdy mogl poprawiac artykul wzorem Wikipedii.
W zadnym wypadku! Jedno nie wyklucza drugiego...

0

Co do HTMLa, calkowicie sie nie zgadzam z jego wylaczaniem (pomijajac kwestie bezpieczenstwa), no bo dlaczego mialo by sie go wylaczac? Bo ktos zamieszanie zrobi? Jesli tak to jego artykul bedzie tak samo wartosciowy co artykul o tresci "", czy podobnej, czego juz sie nie zablokuje.

Myslalem tylko nad nl2br (chodzi np o http://4programmers.net/faq.php?id=702 jesli ktos pamieta /komentarz WeeRa duzo wyjasnia/) i na swojej stronce rozwiazalem to tak, ze mozna wstawic '' przed \n, wtedy calosc jest usuwana (nie ma br'a).

Edycja artow, powiem tak jak robie na http://www.osdev.devtown.net/, chce zeby kazdy mogl edytowac arty i jest mozliwosc cofniecia artykulu (w historii obok kazdego wpisy jest polecenie przywroc /o ile pozwalaja na to uprawnienia/), mozliwosc cofniecia calego serwisu do okreslonej daty i oczywiscie czyszczenia historii (zakladajac, ze zmiany sa czeste a kopie artykulow duzo zajmuja).

Qyon napisał(a)
Adam Boduch napisał(a)

To drugie kloci sie z pomyslem, aby kazdy mogl poprawiac artykul wzorem Wikipedii.
W zadnym wypadku! Jedno nie wyklucza drugiego...

A jednak, chce poprawic literowke i musze wyslac do moda, lub dostosowac jakos wyglad, gdzie zapisuje sie artykul kilka razy pod rzad.

0

podzial na kategorie w Download/Artykulach

tak tak tak! nareszcie będzie można coś znaleźć. proponuję zrobić tak jak w faq - jeden artykuł może się znajdować w wielu kategoriach.

0

Mam "wizje" na podstawie ktorej widze serwis 4programmers.net bardziej przypominajacy mechanizm wiki [green] Mysle ze bedzie to uproszczone, dobre rozwiazanie, zmniejszajace liczbe tabel, rozwiazanie ktore spowoduje rozwoj serwisu. W jego zamierzeniu jest rezygnacja z projektu RoadRunner na rzecz Coyote, tj. dodanie do Coyote mozliwosci latwego tworzenia artykulow oraz hasel encyklopedii.

Juz wyjasniam o co chodzi... W zamierzeniu wszystko pozostanie tak jak jest do tej pory. Tj. w menu po prawej bedzie lista dzialow, tj. "Delphi", a w nim "Artykuly", "FAQ". Ta lista dzialow bedzie generowana automatycznie (nie statycznie, w szablonie jak to jest do tej pory), zapisywana w cache celem przyspieszenia.

Zalozenia nowego mechanizmu:

a) latwe tworzenie nowych hasel (artykulow) oraz mozliwosc ich edycji przez innych userow
b) proste tworzenie kategorii (artykul moze byc jednoczesnie kategoria)
c) historia zmian
d) linki w postacii 4programmers.net/Delphi/FAQ/Jak_wylaczyc_system (jeszcze nie wiem jak to zrobic :D )

Teraz wyjasnie bardziej obrazowo, o co mi chodzi :]
User widzi po prawej stornie liste glownych kategorii serwisu, czyli jedna z kategorii glownych - "Delphi", pod nia "Artykuły", "FAQ", "Gotowce". Kazda z tych kategorii moze miec kolejne pod kategorie jak "WinAPI", ".NET" itp... Jednak w menu po prawej wyswietlane sa tylko kategorie do dwoch poziomow zaglebienia.

Klikam na kategorie "Delphi". Widze opis jezyka, jego historie (to moze byc artykul krotki poswiecony Delphi, oczywiscie tak jak kazdy artykul - moze byc prosto edytowany). Ponizej dynamicznie generowana lista artykulow z tej kategorii, moze tez lista pod kategorii. Mam nadzieje ze to jest dosyc zrozumiale :)

Na tej samej zasadzie mozna by w prosty sposob tworzyc strony serwisu, takie jak. "regulamin", "kontakt", "pomoc", niezwiazane z zadna kategoria.

Oto uproszczona specyfikacja wstepna tabel:

SPECYFIKACJA
------------------

1) Tabela `coyote_article`

---------------------------------------------
article_id          |  ID artykulu
article_subject  |  Tytul, np. "Delphi", "Jak zamknac system" itp.
article_lang      |  Jezyk w ktorym napisano tekst (opcjonalnie)
article_counter |  Licznik odwiedzin
article_lock      |  Wartosc "1" oznacza, ze artykul jest zablokowany

2) Tabela `coyote_text`

---------------------------------------------
text_id         |  Id artykulu (odpowiada kolumnie article_id z tabeli rr_article)
text_content |  Tresc artykulu w danej wersji
text_time     |  Czas napisania tekstu
text_log       |  Opis zmian
text_user     |  ID usera 
text_ip         |  IP usera

Te obie tabele beda sie wzajemnie uzupelniac. Trzeba by bylo pomyslec takze o jakims parametrze w tabeli coyote_text, ktory oznacza "najswiezszy" tekst. Oczywiscie to bedzie mozna odczytac po dacie napisania artykulu, lecz w przypadku wiekszej ilosci tekstu i zmian, to moze spowodowac wolne dzialanie bazy. 

Nalezy takze zastanowic sie co z kategoriami. Bowiem w zalozeniu, kazda kategoria moze posiadac pod kategoria, a ta z kolei moze posiadac inne kategorie. Drugie zalozenie jest takie ze jeden artykul moze byc przypisany do kilku kategorii.

0

Troche szkoda rr user image ale mówi sie trudno :( Natomiast te zmiany imo powinny poprawić jakość merytoryczną serwisu, zbudowac opinię nowoczesności i spopularyzują coyota jako cms, więc jest ok

0

Alez nic sie nie zmarnuje :) Pomysly, wizje oraz dotychczasowy kod zostana wykorzystane w coyote :) Powiedzmy, ze bedzie to encyklopedia (bo jestem pewien ze do tego stopnia sie rozwinie 4programmers.net) nie dzialajca na osobnej domenie/serwisie.

0

ale tak jak forum będzie to nieodzowna część coyote'a :P ale dobry pomysł, i tak jeszcze nie widziałem linijki kodu RR

0

Fajno, tylko IMHO powinno być to oddzielone tak, jak forum - na stronie głównej tylko nowości + link do encyklopedii.

0

Może nie widzę do końca idei, ale nie podoba mi się pchanie w Coyote takich wielkich elementów jako części składowej.
Będę chciał postawić sobie forum a muszę dodawać dodatkowe ciężary.. :(

Bardziej bym widział takie coś:
Instalujemy Coyote i zaznaczamym czy chcemy mieć:
[ ] strona główna (wraz z wszystkimi tymi FAQ/Art)
[ ] forum
[ ] ten niby RR
[ ] buglista
[ ] może coś tam w przyszłości

czyli jakieś takie jakby rozszerzenia - wiem, że wymagają sporo pracy, ale to by znacznie uelastyczniło Coyote - i pozwalało na pisanie własnych wtyczek. Może za dużo na Mambo siedziałem [choć nie podoba mi się] ale takie coś pozwala łatwo dostosować system do własnych potrzeb.

Jeśli całość pójdzie tylko w kierunku 4p to zapalę świeczkę na parapecie... :(

0

Taka wersja wtyczkowo-modulowa jaka przedstawiles jest jak najbardziej do zrobienia, i ja tez jestem "za". Trzeba by jednak pomyslec troszke jak to zrobic, rozpisac jakas specyfikacje... ale takie opcje przy instalacji by sie przydaly.

0

Kolejna czesc specyfikacji :)

1) Linki beda mialy postac: 4programmers.net/text/Delphi/Gotowce/Jak_zamknąć_system, 4programmers.net/text/Pascal/FAQ itp... Wiaze sie to z tym, ze dzialow "Gotowce" moze byc kilka, w kategoriach "Delphi", "Pascal", itp. Taka budowa linkow (mimo ze dluga) na pewno przyczyni sie do lepszego indeksowania owych artykulow przez wyszukiwarki oraz umiejscowienia tych linkow na wyzszych pozycjach.

2) Poprawiona specyfikacja tabeli coyote_article

Do tabeli trzeba dodac pole article_namespace (przestrzen nazw). Dzieki temu bedzie mozna odroznic czy artykul to jednoczesnie nazwa kategorii czy szablon czy "wolny artykul".

3) Specyfikacja tabeli coyote_cat

Tabela ta powinna przechowywac ID kategorii oraz ID artykulow ktore do niej przynaleza.

---------------------------------------------------------
cat_id               |     ID kategorii
cat_article         |     ID artykulu ktory przynalezy do kategorii

4) Specyfikacja tabeli coyote_tree

System ma takze umozliwiac wyswietlanie drzewa kategorii w postacii hierarchicznej. W tym celu potrzebna jest tabela ktora przechowuje ID kategorii oraz ID rodzicow.

-----------------------------------------------------------
cat_id           |   ID kategorii
cat_parent    |   ID kategorii-rodzica
left_id           |  Pole uzywane do prezentacji danych
right_id         |  j/w

5) Mozliwosc tworzenia szablonow

Tak jak na wikipedii. Szablony beda mogly byc wstawiane w tekst - np.:

<template name="szablon" parametr1="wartosc parametru">

6) Specyfikacja tabeli coyote_link

----------------------------------------------------------
link_source      |   ID artykulu w ktorym znajduje sie link
link_dest          |  ID artykulu do ktorego prowadzi link

Jak wiadomo, w poszczególnych tekstach mogą znajdować się odnośniki do innych artykułów w serwisie. W tekstach, odnośniki do innych artykułów mogą być zawarte w znacznikach <url>. Wyobraźmy sobie sytuacje, w której w jednym tekście istnieje 50 odnośników do innych artykułów. Teraz, w trakcie generowania strony, należy sprawdzić, każdy z tych odnośników, czy aby na pewno artykuł o danym tytule znajduje się w bazie danych. Wymagałoby to dodatkowych zapytań do bazy danych. Dlatego lepszym rozwiązaniem będzie utworzenie tabeli coyote_link, która posiada jedynie dwa pola (link_source, link_dest). Pierwsze przechowuje ID artykułu, w którym znajduje się odnośnik, a drugie ID artykułu do którego prowadzi odnośnik.

W trakcie edycji tekstu musimy dokonać zmian, które przedstawiłem w trzech punktach poniżej:

  1. Podczas edycji tekstu o ID = N , przy pomocy wyrażeń regularnych, pobieramy wszystkie znaczniki <url> z tekstu.
  2. Z tabeli rr_link kasujemy wszystkie rekordy, w których link_source = N.
  3. W pętli wysyłamy zapytania sprawdzające, czy w bazie istnieje artykuł o takim tytule. Jeżeli istnieje, pobieramy jego ID, przechodzimy do punktu 4; jeżeli nie - przechodzimy do następnej iteracji pętli.
  4. Do tabeli coyote_link zapisujemy dane: ID artykułu edytowanego (w tym wypadku N) oraz ID artykułu który uzyskaliśmy w punkcie 2.

Podczas odczytu treści danego artykułu z bazy danych musimy wysłać do bazy zapytanie, w którym żądamy zwrócenia wszystkich rekordów, w których link_source = N. Zapytanie musi być łączone i oprócz link_dest zwracać także tytuł artykułu określonego w link_dest. Na tej podstawie, ponownie korzystając z wyrażeń regularnych pobieramy znaczniki <url> i zastępujemy je odpowiednimi odnośnikami XHTML. Jeżeli tytuł artykułu pobrany z wewnątrz znacznika <url> nie odpowiada żadnemu tytułowi pobranemu z bazy danych, to oznacza, że takiego artykułu jeszcze nie napisano.

Podczas usuwania danego tekstu (wraz z jego poprzednimi kopiami) należy wysłać zapytanie usuwające z tabeli coyote_link wszystkie wiersze w których kolumna link_source lub link_dest odpowiadają ID kasowanego artykułu.

Nalezy rozwazyc jeszcze jedna sytuacje... Mamy artykul X ktory zawiera link do nieistniejacego artykulu Y. Teraz ktos utworzy artykul Y, lecz w bazie brakuje informacji potrzebnych do tego, aby w artykule X "podswietlic" link odpowiednio, tak, aby user wiedzial ze taki artykul istnieje. Mozna rozwazyc pomysl utworzenia jeszcze jednej tabeli coyote_broken zawierajacej informacje o nieistniejacych jeszcze, linkach.

-----------------------------------------------
link_source      |    ID artykulu w ktorym umiesczono nieistniejacy link
link_text          |    Fraza

Np.

24 | preg_match
24 | preg_replace

</url></url></url></url>

0

Nalezy tez odpowiedziec na pytanie o rozwoj Coyote... ja do tej pory bylem za tym, aby Coyote byl systemem ogolnegoprzeznaczenia - jak setki innych CMS'ow... teraz juz nie jestem taki pewien, nie wiem czy rozwijac Coyote pod katem serwisu programistyczno-informatycznego, pod katem 4programmers.net, nie zwracajac uwagi na to, ze nie bedzie typowym CMS'em jak Mambo I tak nie ma szans zwojowac rynku, istnieja setki lepszych CMS'ow (jak Mambo) czy kompletnych kombajnow jak ezPublish...

IMHO to bardzo ważna kwestia. Coyote w zasadzie już stał się dostosowany głównie dla serwisu 4programmers, i blado wypada w porównaniu z innymi systemami. Powiem tak: dostosowanie tylko do serwisu 4p zachęci do większej pracy [green]

0

Chciałbym tylko taką małą propozycję dać. A mianowicie wykorzystać coś bardziej miejsco-oszczędnego jeśli chodzi o zapisywanie kolejnych wersji artykułów. funkcje służące do czegoś takiego (kilkanaście-kilkadziesiąt linii kodu) w PHP mogę tutaj podrzucić, jeśli uważacie, że jest to dobry pomysł. Myślę, że członkowie Epsisoft wiedzą coś więcej na temat mojej propozycji i sposobów jej wykorzystania, gdyż zamierzamy te same funkcje zastosować w projekcie CubeCVS.

0

Oto propozycja wygladu strony glownej w skorce subMain:

user image

juz przerobione na XHTML.
Pewnie zauwazacie brak menu po prawej :) Ale to tylko na stronie glownej - na pozostalych podstronach jest po staremu.
Na samym dole (czego juz nie widac na screenie) beda wyswietlane newsy. Zarowno dotyczace tego co nowego zostalo dodane na stronie, jak i newsy z RSS. Na gorze po prostu szkoda miejsca na naglowki RSS, ktore i tak sa rzadko czytane. W zamysle takze, gorna czesc strony bedzie mogla podlegac edycji :)

0

Ten screen specjalnie taki mały aby nie było widać wałków? ;p

Adam Boduch napisał(a)

Na gorze po prostu szkoda miejsca na naglowki RSS, ktore i tak sa rzadko czytane.
Kpisz? Zaraz po forum to jedyna rzecz, którą tak pilnie śledzę i czytam większość nowych newsów prowadzących do idg.pl - pełno tam moich komentarzy [i kłótni.. i wrzut do redakcji.. i normalnych też ;p] - szkoda, że nie ma wyszukiwarki po autorach komentarzy...

0

Marooned, to ze ty czytasz nie oznacza ze wiekszosc [green] Wiekszosc z tych newsow sa czytane zero razy, rekordowe po kilkadziesiat (chodzi mi o przekierowania do pelnych artykuylow) i dlatego w glownej pojada na sam dol :P

0
Adam Boduch napisał(a)

Marooned, to ze ty czytasz nie oznacza ze wiekszosc [green]

To my z Maćkiem chcemy mieć ustawowe dwa miejsca w sejmie, jako że jesteśmy w mniejszości :P

W ogóle to wydaje mi się ta strona trochę przytłaczająca. Zresztą obecna w submain też.

0

I ja się przyłączę - ustawę się zmieni ;P

0

A ja bym prosił więcej newsów z serwisu / odnośniki do poprzednich stron newsów. 3 najnowsze to trochę mało, zwłaszcza, że ostatnio się jakoś tak więcej tego pojawiło :)

0

A może krok dalej? :>

[newsy]

  1. ..
  2. ..
  3. ..
    [starsze]

[nowe arty]

  1. ..
  2. ..
    [starsze]
    ...

i link 'starsze' za pomocą XMLHttpRequest podmienia tylko dany fragment strony, dynamicznie :)

0

Bedzie, zrobie. Na screenie tego nie widac, ale belka "Nowosci" jest podlinkowana - bedzie wyswietane wiecej nowosci. Co do linka do spisu newsow/komunikatow to tez dam gdzies linka bardziej widocznego.

Co do "Witamy..." to czemu nie? :))) Ta czesc strony jest edytowana dynamicznie, zapisywana w bazie...

1 użytkowników online, w tym zalogowanych: 0, gości: 1