Mylenie technologii z linkiem

7

Nie wiem do końca czy to jest bug czy nie, ale ostatnio odpowiadałem na jeden post i napisałem coś w stylu:

Może spróbujesz Angular/Vue.js/React?

I jak pewnie widzicie, część Vue.js/React? jest parsowana jak Uri: domain.js/path? Oczywiście parser działa dobrze, ale może możnaby wykluczyć jakieś słowa kluczowe? np właśnie vue.js, jeśli nie mają http://? Oczywiście keyword nie zadziała ze wszystkim, bo np biblioteka socket.io znajduje się pod adresem http://socket.io

Zwłaszcza rozszerzenie .js bym brał pod uwagę, bo większość technologii takich właśnie ma nazwy: p5.js, d3.js, pdf.js, node.js, backbone.js, React.js pewnie są jeszcze inne - bo raczej inne języki nie mają takiego trendu - nie ma bibliotek Carbon.php :D Albo spring.java

Bug/zgłoszenie do interpretacji przez @Adam Boduch ja nie wiem co o tym myśleć.

2

A jak ktoś kupi sobie taką domenę i będzie chciał podlinkować to potem zglosi to jako błąd

0
KamilAdam napisał(a):

A jak ktoś kupi sobie taką domenę i będzie chciał podlinkować to potem zglosi to jako błąd

Dopisze http://

3
TomRiddle napisał(a):

Oczywiście parser działa dobrze […]

Adresy powinny posiadać prefiks http:// lub https://, więc nie działa dobrze.

1
furious programming napisał(a):
TomRiddle napisał(a):

Oczywiście parser działa dobrze […]

Adresy powinny posiadać prefiks http:// lub https://, więc nie działa dobrze.

No właśnie nie jestem tego pewien. Pisałem nie dawno unit testy pod parser linków w coyote, i tam było dokładnie wyszczególnione ze case bez scheme (tzn samo www.) jest linkiem. Trzeba by spytać kogoś kto wie co powinno być linkiem a co nie.

Możnaby np sprawdzić jak github albo Facebook rozumie linki, i próbować się wzorować.

3
TomRiddle napisał(a):

Trzeba by spytać kogoś kto wie co powinno być linkiem a co nie.

No zapytałeś, więc Ci odpowiedziałem. Adres zaczyna się od protokołu, a bez niego dany tekst może być wszystkim. Nawet jeśli za adres uznawać ciąg zaczynający się od www., to w dalszym ciągu parser działa źle, bo Tobie zrobił link, choć tego prefiksu nie podałeś.

Możnaby np sprawdzić jak github albo Facebook rozumie linki, i próbować się wzorować.

Można też pomyśleć samodzielnie i wziąć sprawę na logikę. W końcu to forum programistyczne. ;)

6

np. ktoś może wymieniać różne odmiany biblioteki Rx:

rx.NET/RxJS/RXJava

i się robi link, bo mylnie bierze .net za domenę.

poza tym parser jest jakiś niespójny:
example.com
example.com/1
example.com/1/
example.com/a
example.com/a/
example.com/fooo

potencjalny kawałek kod, który mógłby ktoś wkleić, a zapomniałby umieścić go w znacznikach:
element.style.left/2.5

1

Biorąc pod uwagę wypowiedź @LukeJL oraz @furious programming trzeba by się zastanowić co jest mniejszym złem:

  • Czasem coś co nie jest linkiem, jest oznaczone jako link (vue.js/react? jako link)
  • Ktoś zapomni http://, i link nie zostanie pokazany jako link (łącznie z linkami które już teraz są na forum).
1

Mniejszym złem będzie uznawanie za adres tekstu, który:

  • rozpoczyna się od protokołu (np. https://) lub prefiksu strony internetowej (np. www.),
  • pasuje do wzorca adresu strony (posiada prefiks, domenę oraz rozszerzenie) lub wzorca adresu e-mail.

To powinno rozwiązać problem z linkami, a na pewno znacząco zmniejszy ułomność parsera w praktyce.

3
TomRiddle napisał(a):

Możnaby np sprawdzić jak github albo Facebook rozumie linki, i próbować się wzorować.

Na github, link musi mieć http:// albo www aby był parsowany.

1
Adam Boduch napisał(a):
TomRiddle napisał(a):

Możnaby np sprawdzić jak github albo Facebook rozumie linki, i próbować się wzorować.

Na github, link musi mieć http:// albo www aby był parsowany.

Tak teraz myślę że github używa się chyba parsera markdown, więc na tym można by się wzorować.

Parser linków już dobrze znam w coyote, więc mogę wrzucić jutro PRka.

@Adam Boduch Tylko pytanie czy idziemy z tym podejściem GH, i czy wgl poprawiamy linki?

0

Nie wiem jak Facebook rozumie linki, ale WhatsApp traktuje m.in. jako link...

4

Mamy markdown. To co ma być linkiem niech będzie w odpowiednich znacznikach i po problemie. Każdy link trzeba zdefiniować ręcznie - po kiego grzyba zastanawiać się czy coś jest linkiem czy nie, skoro można tego wymagać od użytkownika?

1

Wymaganie protokołu lub jawnego oznaczania linków jest utrudnianiem życia użytkownikowi. Wszystko, co potencjalnie jest linkiem powinno być pokazywane jako link, a jak chce się odfiltrować false positive, to przy zapisywaniu wiadomości do bazy danych można strzelić do sieci i sprawdzić, czy dana domena istnieje (tylko trzeba uważać na otwieranie linków, bo to niebezpieczne i może mieć efekty uboczne, wystarczy zwykły nslookup).

3

Wymaganie protokołu lub jawnego oznaczania linków jest utrudnianiem życia użytkownikowi.

Dla mnie to uproszczenie, więc się z Tobą nie zgodzę.

Wszystko, co potencjalnie jest linkiem powinno być pokazywane jako link

To co jest linkiem powinno być pokazywane jako link. Nie to co potencjalnie jest linkiem. A jaka część posta/komentarza jest linkiem wie tylko autor. Wymuszenie na nim wskazania linku jest naturalnym krokiem do łatwej komunikacji

0
Burdzi0 napisał(a):

Dla mnie to uproszczenie, więc się z Tobą nie zgodzę.

Spoko. Wprawdzie nie rozumiem, dlaczego wolisz wykonywać pracę, którą może spokojnie zrobić komputer, ale to oczywiście Twój wybór.

To co jest linkiem powinno być pokazywane jako link. Nie to co potencjalnie jest linkiem. A jaka część posta/komentarza jest linkiem wie tylko autor. Wymuszenie na nim wskazania linku jest naturalnym krokiem do łatwej komunikacji

W idealnym świecie tak, w rzeczywistości użytkownicy są leniwi i nie chce im się myśleć, a system nie powinien ich do tego zmuszać, jeżeli nie jest to niezbędne. Tak jak mówię, można iść na łatwiznę i wszystkie potencjalnie linki podkreślać, można zrobić troszkę więcej i używać nslookup, można budować na tym modele ML, ale użytkownikom w większości nie chce się oznaczać linków przy pisaniu onet.pl (tak jak nie chce im się używać TeX-a, formatować kodu, dodawać tagów czy innych rzeczy, które zazwyczaj są mile widziane) i wymaganie tego od nich jest moim zdaniem słabe, bo zwala pracę z programisty na użytkownika.

1

@TomRiddle: jeżeli chce Ci się robić takiego PR chętnie zarobię merge

1

A może zamiast kombinować… zostawmy jak jest.

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