Dyskusja wikiprojektu:Sprzątanie kodu/Gadżet

Treść strony nie jest dostępna w innych językach.
Z Wikipedii, wolnej encyklopedii

Forki[edytuj kod]

Aktualnie istnieją dwa forki narzędzia: user:Nux/wp_sk.js i user:BartekChom/wp_sk.js. Prawdę mówiąc, nie wiem, czemu tak jest, ale nie muszę chyba wyjaśniać, że jest to sytuacja niezbyt komfortowa - forki mają różne funkcje, trudne jest dodanie czegoś do obydwu, są problemy z gadżetami itp.

W związku z powyższym postuluję do autorów o połączenie tych dwóch narzędzi w jedno, które będzie można łatwo edytować, i które można umieścić np. tutaj.

A jeżeli chodzi o problemy z powodu tego, że niektóre funkcje się "gryzą" (np. wersja Nuxa nie dodaje spacji po *, : itp., a wersja BartkaChoma owszem) - można dodać opcje konfiguracyjne (patrz też poniżej).

Z kolei kwestia problemów ze zwykłymi userami, którym nagle skrypt przestałby działać - wystarczy w miejscu starych skryptów wstawić wywołanie nowego przez importScript(), może połączone z jakąś nienachalną wiadomością.

Pozostaje już tylko jeden problem: kto to zrobi. Jeżeli nie będzie chętnego, z przyjemnością załatwię to ja.

Z nadzieją na pozytywne komentarze, Matma Rex aka matematyk 14:35, 20 cze 2008 (CEST)[odpowiedz]

Jestem bardzo bardzo za. Sam przez to zamieszanie zrobiłem sobie "prywatnego" forka, do którego dodałem opcje, które przydają mi się osobiście. O wiele bardziej by mi się jednak podobało takie połączone narzędzie - a niżej wspomniana budowa modułowa byłaby super :) Pozdrawiam ToSter→¿? 15:04, 20 cze 2008 (CEST)[odpowiedz]
Sprawdziłem twojego forka - całkiem fajne zmiany. Jak połączenie dojdzie do skutku, pewnie też zostaną dodane. Matma Rex aka matematyk 15:27, 20 cze 2008 (CEST)[odpowiedz]
Szczerze powiedziawszy, to nie ja jestem forkiem ;), ale po weekendzie przyjrzę się różnicom i wprowadzę część po przetestowaniu. Jeśli czegoś będzie brakować w mojej wersji, to mogę dodać, ale... Ale nie dodam na pewno tzw. opcji ryzykownych, bo z mojego doświadczenia wynika, że przynajmniej część osób nie przejmuje się lub nie rozumiem dlaczego te zmiany są ryzykowne. Także bez ładnego interfejsu (z potwierdzaniem każdej zmiany) nie będę wprowadzał wersji ryzykownych.
Pomyślę nad dodaniem wywołania funkcji użytkownika np. po wszystkich wprowadzonych zmianach, ale muszę się zastanowić jakie może to stwarzać problemy i w którym dokładnie miejscu takie wywołanie powinno się znajdować. --Nux (dyskusja) 16:06, 20 cze 2008 (CEST)[odpowiedz]
Ee, zaraz, ale ja myślałem o całkowitym połączeniu tych dwóch wersji oraz prowizorycznym załatwieniu sprawy różnic w nich poprzez parę dodatkowych zmiennych konfiguracyjnych, a potem przejściu do rozmyślań nad budową modułową, a nie o "wyrównaniu" obu forków. Matma Rex aka matematyk 17:55, 20 cze 2008 (CEST)[odpowiedz]
Nie lubię prowizorki w moim oprogramowaniu, ale jeśli chcesz stworzyć kolejnego forka, tylko z mostami między zębami ;), to oczywiście licencja na to pozwala. Do swojej wersji mogę wprowadzić zmiany, które będą nieszkodliwe dla artykułów, co jednak wymaga przetestowania zmian. W kwestiach nietechnicznych typu "wpisujemy spacje po znaku listy lub nie", powinna się tak naprawdę wypowiedzieć społeczność wikipedyczna, a nie tylko użytkownicy WP:SK. A jak już jesteśmy przy tym, to (o ile dobrze pamiętam) akurat w kwestii spacji nie było jednomyślności (co było zresztą powodem tego, że nie naprawiałem tej funkcjonalności). --Nux (dyskusja) 21:53, 20 cze 2008 (CEST)[odpowiedz]
Ja nie chcę tworzyć forków, ja je chcę ponownie połączyć w jeden skrypt, za to konfigurowalny. Jeśli chodzi o prowizorkę - użyłem tego słowa, bo chodziło mi o załatwienie do czasu przejścia na modułowość. Matma Rex aka matematyk 23:10, 20 cze 2008 (CEST)[odpowiedz]

Budowa modułowa[edytuj kod]

Proponuję przerobienie skryptu w taki sposób, aby był zbudowany modułowo. Aktualnie jest to po prostu nieuoprządkowana lista poleceń replace(), w budowie modułowej każde zadanie (poprawianie linków, sortowanie interwiki, kategorii) miałoby osobną podfunkcję, a te wszystkie wywoływane byłyby przez funkcję nadrzędną.

Plusy tego rozwiązania:

  • łatwiejsza edycja - nie trzeba przeglądać całego kodu, tylko patrzeć na nazwy funkcji
  • możliwość dokładnej konfiguracji - bo a nuż ktoś nie chce np. dodawać spacji w nagłówkach?
  • możliwość wprowadzenia dodatkowych modułów - takich, które np. są niszowe (porządkowanie infobksów lub nawet pojedynczego infoboksu), powolne (np. wykorzystujące AJAX, np. poprawa redirectów) lub mogące psuć artykuł (np. poprawa najczęstszych ortów)

Minusy:

  • żadnych nie widzę ;)

Z nadzieją na pozytywne komentarze, Matma Rex aka matematyk 14:35, 20 cze 2008 (CEST)[odpowiedz]

Wbrew temu co piszesz polecenia są pogrupowane i uporządkowane, a poprawy linków itp mają osobne funkcje (tylko zbieranie i wstawienie jest rozdzielone bo najpierw wszystko jest zbierane, a potem wstawiane). Co do samej idei modułowości w tym wypadku to jednak widzę pewne minusy (zagrożenia):

  • konflikty między modułami - jeden z modułów będzie zmieniał coś co drugi będzie psuł (inny pomysł na zmianę)
  • problemy z zachowanie zasad modułowości - podobne do powyższego, ale w ujęciu technicznym (to tak jak z tym zbieraniem kategorii)
  • problemy z odświeżaniem - jeśli skrypty będą w osobnych plikach, to przeglądarka może mieć problem z określeniem kiedy jest nowa wersja do pobrania (tak przynajmniej jest w FF)
  • brak kontroli nad poszczególnymi modułami - może to spowodować, że niektórzy będą chcieli coś zrobić tak, a inni siak, chociaż ogólne ustalenia i wytyczne były zupełnie inne.

Poza tym, już pomijając kwestię modułów, nadmierne możliwości konfiguracji są niezgodne z zaleceniem ujednolicania artykułów i kłóci się moim zdaniem z ideą WP:SK.

Pozdrawiam, Nux (dyskusja) 22:56, 20 cze 2008 (CEST).[odpowiedz]

  • Wbrew temu co piszesz polecenia są pogrupowane i uporządkowane - są komentarze, a polecenia dot. jednej rzeczy są zwykle w pobliżu - wiem, zanim zacząłem grzebać w WP:SK, to trochę przeglądnąłem ten skrypt. Ale chodzi mi o pogrupowanie w osobne funkcje, jak zresztą napisałem powyżej.
  • konflikty między modułami, brak kontroli nad poszczególnymi modułami - prawdę mówiąc, nie myslałem o takiej całkowitej wolności w dodawaniu, tylko o dodawaniu ich do samego skryptu' (na jedną stronę - to rozwiąże też problemy z odświeżaniem), ale domyślnie wyłączonych. Skrypty byłyby jakoś zgłaszane, przeglądane przez głównych autorów WP:SK i znawców JavaScript, i dopiero wtedy lądowałyby w skrypcie.
  • nadmierne możliwości konfiguracji są niezgodne z zaleceniem ujednolicania artykułów - nadmierne? Gdzie? Te moduły to byłyby głównie lub tylko, jak już mówiłem, takie, które np. są niszowe (porządkowanie infobksów lub nawet pojedynczego infoboksu), powolne (np. wykorzystujące AJAX, np. poprawa redirectów) lub mogące psuć artykuł (np. poprawa najczęstszych ortów). A jeśli chodzi ci o różnice między skryptami, to znacznie bardziej kłóci się [...] z ideą WP:SK to, że są dwa forki, robiące niekoniecznie te same zmiany.
Mam nadzieję, że wątpliwości zostały rozwiane lub choć "rozmyte", Matma Rex aka matematyk 23:10, 20 cze 2008 (CEST)[odpowiedz]
Nadmierne w zdaniu "bo a nuż ktoś nie chce np. dodawać spacji w nagłówkach?" ;). Wiem czepiam się przykładu, ale jeśli nie uda się wymyślić sposobu na dołączanie zmian niepotrzebnych niektórym ze względu na specyficzną tematykę (rzadko używanych), to nie ma sensu ich wyłączać. Skoro ktoś już ma kod do wykonania danej funkcji sprzątającej, to według mnie nie powinno być żadnego powodu dla którego nie miałby jej wykonać (może poza bardzo specyficznymi funkcjami). Tak naprawdę przeglądanie zmian po WP:SK (tym moim) konieczne jest tylko dlatego, że mogłem nie wziąć czegoś pod uwagę i skrypt coś pomieszał. --Nux (dyskusja) 23:50, 20 cze 2008 (CEST)[odpowiedz]
Racja, przykład nieudany. Wyłączanie tych "niszowych" też może i nie jest zbyt mądre (jedyny powód to to, że sprzątanie może trwać dłużej), za to wyłączenie powolnych (XMLHttpRequest) i mogących psuć (aktualne ryzykowne, poprawa pisowni) jest moim zdaniem dobrym pomysłem.
Aha, cała ta dyskusja raczej nie ma sensu, gdy dalej będzie kilka forków WP:SK - tworzenie jeszcze jednego tylko zagmatwa sprawę. Matma Rex aka matematyk 10:59, 21 cze 2008 (CEST)[odpowiedz]
Zgadzam się, te AJAX-owate powinny być opcjonalne, ale raczej bym to widział jako konfigurację "w locie" (np. z rozwijanym panelem konfiguracyjnym gdzieś przy oknie edycji). Zresztą takie np. sprawdzanie redirectów powinno być zrobione w sposób bardzo przemyślany, żeby nie zabić serwerów (jeden użytkownik oczywiście nic nie zrobi, ale 1000 sprawdzających każdy artykuł z setką linków...).
Co do forków, to powtórzę, że to nie ja je tworzę. Nie mówię tego jako zarzut. Przez spory okres czasu moja aktywność była prawie zerowa i naturalną rzeczą było, że jak był ktoś chętny do rozwijania, to kod się rozdzielił i tamtą wersję wybrano do Gadżetów. Rozumiem też, że część osób jest przywiązana do opcji ryzykownych, ale ja się nie podpiszę pod wersją z ryzykownymi zmianami bez porządnego interfejsu, który wyeliminuje problemy z nadużyciami. --Nux (dyskusja) 19:58, 21 cze 2008 (CEST)[odpowiedz]
raczej bym to widział jako konfigurację "w locie" - jestem za, proponuję konfigurację podwójną albo i potrójną:
  1. konfiguracja na poziomie skryptu
  2. konfiguracja na poziomie postrony usera
  3. konfiguracja w locie z zapisem w cookies (opcja)
Owszem, nie mówię przecież, że to ty tworzysz forki, bo wiem, że to twoja wersja była podstawowa. Uważam jednak, że tworzenie jeszcze jednego jest nonsensem nawet, gdyby miał jakieś dodatkowe funkcje, bo spowodowałoby to galimatias.
a się nie podpiszę pod wersją z ryzykownymi zmianami bez porządnego interfejsu, który wyeliminuje problemy z nadużyciami - jaki interfejs masz na myśli? Matma Rex aka matematyk 20:27, 21 cze 2008 (CEST)[odpowiedz]
Coś w tym stylu jak masz programach biurowych przy sprawdzaniu tekstu (akceptujesz zmiany słowo po słowie). Myślę, że możnaby zrobić akceptację zmianę po jednym akapicie (w sensie blok tekstu oddzielonego dwoma enterami)... Właściwie to właśnie wymyśliłem jak to zrobić, więc może niedługo uda się to opracować. :) --Nux (dyskusja) 09:10, 23 cze 2008 (CEST)[odpowiedz]
Jeśli tak, to wspaniale. No to chyba już wszystkie problemy? Aha, proponuję nie używać tego dokładnego sprawdzania przy "nieryzykownym" WP:SK - tylko to zdenerwuje użytkowników. Matma Rex aka matematyk 10:16, 23 cze 2008 (CEST)[odpowiedz]
Przepraszam. Miałem sesję i nie miałem czasu na Wikipedię. Myślę, że najlepiej, jeśli będzie domyślna wersja z pytaniami przy ryzykownych (i "nie na wszystko"), a da się też jakoś konfigurować przy ręcznym dodawaniu. Zmiany naprawdę najlepiej przedyskutować w szerszym gronie - i pewnie na koniec przegłosować. Akurat trwa dyskusja nad postacią infoboksów. BartekChom (dyskusja) 16:58, 26 cze 2008 (CEST)[odpowiedz]

Oto jak moim zdaniem powinien wyglądać szkielet WP:SK: Wikipedysta:Matma Rex/wpsk.js. Matma Rex aka matematyk 11:03, 23 cze 2008 (CEST)[odpowiedz]

Gotowe![edytuj kod]

Pierwsza wersja beta niewywalająca błędów gotowa - Wikipedysta:Matma Rex/wpsk.js. Myślę, że udało mi się zgrabnie połączyć funkcjonalności obu wersji, są też opcje konfiguracyjne. Do zrobienia pozostało dodanie możliwości zapisu ustawień w cookies i, oczywiście, dokładniejsze testowanie (chociaż to nie powinno być problemem - kopiowałem sprawdzone regexy). Aby przetestować, trzeba dodać do monobooka linię importScript('Wikipedysta:Matma Rex/wpsk.js'). Matma Rex aka matematyk 13:46, 26 lip 2008 (CEST)[odpowiedz]

Sorry, ale tak na moje oko zrobiłeś właśnie to czego nie chciałeś - kolejnego forka. Nie widzę tam np. mojej funkcjonalności związanej z Defaultsortem, więc pewnie opierałeś się głównie na wersji Bartka.
Tak jak pisałem powyżej - wydzielenie większości części kodu moim zdaniem nie ma sensu, bo kod jest i tak pobrany i nie ma żadnych przeszkód by go uruchomić (a przynajmniej nie powinno być). Wg mnie ideą przewodnią SK jest to, żeby ujednolicać kod i ogólniej artykuły. Przy tym WP:SK jest wykonywane raczej przy okazji, a nie zamiast stąd też w swojej wersji zawsze przyjmowałem zasadę, którą można ogólnie określić jako "primum non nocere". Innymi słowy jeśli w choćby jednym przypadku coś działa źle, to poprawiam kod, albo jeśli nie potrafię lub kod zrobiłby się po prostu zbyt skomplikowany w stosunku do zysku to go wywalam. Na dyskusji mojej wersji prawie cały znajdujący się tam kod jest wrażliwy na różne specyficzne przypadki. Większość jeśli nie całość tego kodu jest natomiast w wersji, którą przygotowałeś.
Co do kwestii poza funkcjonalnych - osobiście akurat nie lubię tego stylu programowania w JS. Wiem, że taki drzewiasty zapis obiektów ma swoje zalety - z pewnością kod jest nieco krótszy przez brak powtórzeń - ale za często pracuję na laptopie, żeby móc stosować tyle tabów i zachować czytelność. Poza tym przy tym stylu trzeba stosować trochę więcej komentarzy, bo np. jak widzę "cleanup:function...", to muszę chwilę pomyśleć czego dotyczy, a jak widzę "wp_sk.lnk_map_pl_ibox.cleanup = function...", to bez komentarza i specjalnego oprogramowania wiem o co chodzi. Dlatego uważam, że taki styl raczej powinno się stosować jeśli używa się specjalnego oprogramowania, a potem jeszcze np. zapisuje projekt z zaszyfrowanymi nazwami, żeby utrudnić kradzież komercyjnego kodu. Innymi słowy - mnie raczej utrudniłoby to wprowadzanie zmian niż je usprawniło. --Nux (dyskusja) 16:05, 26 lip 2008 (CEST)[odpowiedz]
Twojej funkcjonalności defaultsort nie ma, ponieważ jako jeden z modułów planuję wprowadzić zmodyfikowaną moją - user:Matma Rex/defaultsort.js.
"pewnie opierałeś się głównie na wersji Bartka" - owszem, kodem początkowym był generalnie jego kod, ale dlatego, że po prostu w tej wersji jest więcej rzeczy -> prościej mi było dodać twoje do jego niż jego do twojego. Ale poza defaultsortem jest wszystko to, co było u ciebie.
"jeśli w choćby jednym przypadku coś działa źle, to poprawiam kod (...)" - w tej wersji, jeśli coś gdzieś będzie się psuło, kod będzie zaznaczony jako ryzykowny, a gdy będzie odpalany kod ryzykowny, wymagane będzie sprawdzenie zmian ("Zapisz" będzie zablokowany).
Co do kwestii pozafunkcjonalnych, to może i masz rację (sam się poważnie zastanawiałem, czy robić tak, jak zrobiłem, czy tak, jak było zrobione poprzednie), i jeśli uważasz, że zmiana stylu ułatwi edycję, to proszę cię, zmień go. Za to jestem całkowicie przeciwny używaniu new Object zamiast {} i new Array() zamiast [], bo to tylko komplikuje i przedłuża kod. Średników zaś nie używam głównie dlatego, że nie trzeba.
Z nadzieją, że się dogadamy, Matma Rex aka matematyk 17:41, 26 lip 2008 (CEST)[odpowiedz]
Tak jak już pisałem - w wersji Bartka jest więcej częściowo dlatego, że wprowadzał zmiany bez szerszych testów. Takie jest przynajmniej moje wrażenie, bo po moich testach część regexpów musiałem wycofać, zmienić lub w ogóle nie wprowadzałem do właściwej wersji. Moim zdaniem, lepiej oprzeć się na wersji o której wiadomo, że działa, a nie wprowadzać dziurawą i stopniowo usuwać dziury po testach na żywym organizmie.
Przynajmniej na razie przyznaję, że nie palę się do zmiany Twojej wersji - i tak mam mało czasu by rozwijać moją wersję. --Nux (dyskusja) 07:12, 30 lip 2008 (CEST)[odpowiedz]
Jeszcze się dokładnie nie przyjrzałem, ale w miarę mi się podoba. Mam nadzieję, że uda się Wam jakoś porozumieć i powstanie w końcu jeden projekt. Daleki jestem od uznawania siebie za współautora - dodałem parę regexów przydatnych ogólnie, ale większość przydaje się tylko w artykułach tatrzańskich, które edytuję najczęściej - w innych może sporo popsuć nawet. Trzeba się przyjrzeć jeszcze wszystkim wyrażeniom. Wg mnie istotne jest, żeby dopracować poprawianie dywizów na średniki (omijać wystąpienia w nazwach plików i linkach), żeby można je przesunąć z ryzykownych do nieryzykownych operacji - na pewno wiele osób używających WP:SK będzie się obawiało tego "ryzyka". Ogólnie zmiany oceniam na plus, ale beta to beta :) ToSter→¿? 21:21, 4 sie 2008 (CEST)[odpowiedz]
Wszystko wskazuje, że będę mógł zamknąć swoją wersję i zacząć korzystać z tej. Proszę tylko o uwzględnienie ostatnich zmian w mojej wersji [1]. I zwracam uwagę, że tutaj ma być właśnie specjalne gie: str = str.replace(/\{\{IPA\|g\}\}/g, '{{IPA|ɡ}}') BartekChom (dyskusja) 23:34, 7 sie 2008 (CEST)[odpowiedz]

"znacząco utrudnia to przeglądanie zmian redaktorom"[edytuj kod]

@PG

Jeśli zdanie poniżej jest nadal aktualne, przydał by się opis chociaż jednego przykładu, który najbardziej znacząco utrudnia przeglądanie zmian redaktorom.

Dodane 1 kwi 2021:

"Nie używaj tego gadżetu na artykułach z nieprzejrzanymi zmianami – znacząco utrudnia to przeglądanie zmian redaktorom. Wyjątek stanowią artykuły nieposiadające jeszcze wersji przejrzanej." MarMi wiki (dyskusja) 15:23, 21 paź 2021 (CEST)[odpowiedz]

Źródło: „https://pl.wikipedia.org/w/index.php?title=Dyskusja_wikiprojektu:Sprzątanie_kodu/Gadżet&oldid=73268365”