Muszę opracować widżet, który będzie używany przez stronę trzecią. To nie jest aplikacja do wdrożenia w serwisie społecznościowym. Mogę dać użytkownikom witryny link do wykorzystania jako src iframe lub mogę go rozwinąć jako żądanie JavaScript.Widget - Iframe kontra JavaScript
Czy ktoś może mi powiedzieć kompromisy między dwoma podejściami (IFrame kontra JS)?
Miło wiedzieć, że to nie może być wdrożony w portalu społecznościowego ... że tylko pozostawia resztę sieci ;-)
Jakie byłyby najbardziej przydatne, zależy od widgetu. Ramki IFrame i javascript generalnie służą zupełnie innym celom i mogą być mieszane (tj. Javascript wewnątrz elementu iframe lub javascript tworząc element iframe).
Szukałem o tym samym pytaniem i znalazłem ciekawy artykuł:
http://prettyprint.me/prettyprint.me/2009/05/30/widgets-iframe-vs-inline/
Widżety to małe aplikacje internetowe, które mogą być łatwo dodana do jakiejkolwiek strony internetowej . Są one czasami nazywane Gadżetami i są szeroko wykorzystywane do wzrostu liczby stron internetowych, blogów, serwisów społecznościowych, spersonalizowanych stron domowych, takich jak , takich jak iGoogle, my Yahoo, netvibes itp. Na tym blogu używam kilku widgetów , takich jak licznik RSS po prawej stronie, która pokazuje, ilu użytkowników subskrybuje tego bloga (nie martw się, to się rozwinie, to jest nowy blog ;-)). Widżety są świetne w tym sensie, że są one niewielkim, wielokrotnego użytku elementem funkcjonalności, który nawet nie-programista może wykorzystać do wzbogacenia swojej strony.
Pisałem kilka takich widgetów upływem czasu zarówno „surowe” widgety które można uzyskać w dowolnym miejscu osadzone, a także gadżetów iGoogle będących bardziej uporządkowany, worpress *, TypePad i bloger widgety, więc jestem szczęśliwy , aby podzielić się moim doświadczeniem.
Jako autor widget dla widżetów, które są uruchamiane po stronie klienta (proste osadzenia kodu HTML), które mają do wyboru pisanie widget wewnątrz iframe lub po prostu inline stronę i uczynić go częścią dom od strona hostingowa. Reszta postu omawia za i przeciw obu metod.
Jak to jest technicznie zrobione? Jak używać elementu iframe lub implementować wbudowany widget?
Elementy iframe są nieco łatwiejsze do wdrożenia.Poniższy przykład powoduje prosty widget iframe: http://my-great-widget.com/widgwt 'szerokość = "100" wysokość = "100" frameborder = '0'>
frameborder =' 0 ' służy do upewnienia się, że element ifrmae nie ma granicy , więc wygląda bardziej naturalnie na stronie. Za dostarczanie zawartości widżetu jako kompletnej strony HTML odpowiada osoba odpowiedzialna.
Inline gadżetów może wyglądać następująco:
funkcji createMyWidgetHtml() {return "Hello world widgetów"; } document.getElementById ('myWidget'). InnerHTML = createMyWidgetHtml(); Jak widać, funkcja createMyWidgetHtml() jest odpowiedzialna za utworzenie rzeczywistej zawartości widgetu i niekoniecznie musi się z nią skontaktować rozmawiając z serwerem, aby to zrobić. W przykładzie iframe musi być serwer . W przykładowym wierszu nie musi być serwera, , ale w razie potrzeby możliwe jest uzyskanie danych z serwera, co w rzeczywistości jest bardzo częstym przypadkiem, widżety zazwyczaj wywołują po stronie serwera kod . Korzystanie z kodu strony po stronie serwera jest wywoływane za pomocą javascript on-demmand .
Podsumowując, w przypadku elementu iframe po prostu umieszczamy kod iframe HTML i kierujemy źródło elementu iframe do lokalizacji, w której obsługuje zawartość widgetu. W przypadku inline my tworzymy zawartość lokalnie używając javascript. Oczywiście można łączyć korzystanie z iframe z javascript oraz korzystać z metody inline z wywoływaniem po stronie serwera, nie jesteś przez to ograniczony, ale ścieżki rozpoczynają się różnie.
Więc co to jest wielka sprawa? Co za różnica? Istnieje kilka ważnych różnic, więc tutaj rozpoczyna się interesująca część postu .
Bezpieczeństwo. Widżety iFrame są bezpieczniejsze.
Jakie ryzyko nakładają gadżety i kto jest narażony na ryzyko? Użytkownik witryny i reputacja witryny są zagrożone.
Z wbudowanymi gadżetami przeglądarka uważa, że kod źródłowy gadżetu pochodzi z witryny hostingowej. Załóżmy, że przeglądasz swoją ulubioną aplikację pocztową http://my-wonderful-email.com, a ta aplikacja pocztowa zainstalowała widget wyświetlający zegar z http://great-clock-widgets.com/. Jeśli te widgety są zaimplementowane jako wbudowany widget , przeglądarka uważa, że kod widżetu pochodzi z my-wonderful-email.com, a nie na great-clock-widgets.com, więc pozwoli to ostatecznie uzyskać dostęp do kodu widżetu. do ciasteczek, których właścicielem jest my-wonderful-email.com, a zły autor widżetu ukradnie Twój email . Ważne jest, aby zdać sobie sprawę, że przeglądarki nie dbają o to, gdzie hostowany jest plik javascript; o ile kod działa na tej samej ramce , przeglądarka traktuje cały kod jako originationg w domenie ramki . Tak więc, gdy użytkownik ucierpi, tracąc kontrolę nad kontem e-mailowym konto i moja cudowna wiadomość e-mail zostaną zranione przez utratę reputacji.
Jeżeli ten sam zegar by zdobyć realizowane wewnątrz iframe i źródła iframe różni się od źródła strony (co jest częsty przypadek, na przykład źródło strona jest my-wonderful-email.com i gadżet source is great-clock-widgets.com), wtedy przeglądarka nie zezwala na dostęp widgetów zegara do ciasteczek na stronie, ani nie zezwoli na dostęp do żadnej innej części dokumentu hostingowego, w tym strony hosta hosta . To jest bezpieczniejsze. W rzeczywistości na stronach osobistych takich jak iGoogle nie można nawet umieszczać wbudowanych gadżetów, a gadżety iframe są dozwolone tylko w przypadku gadżetów iframe: . (Gadżety wbudowane są dozwolone tylko w rzadkich przypadkach dopiero po szczegółowej kontroli przez zespół iGoogle, aby upewnić się, że nie są złośliwy)
Podsumowując widgety iframe są bardziej bezpieczne. Jednak są one również bardziej ograniczone pod względem funkcjonalności. Następnie omówimy, co utracisz w funkcji .
Wygląd i styl W gadżetów bitewnych z wizerunkiem (zwykle **) wygrywa . Zaletą jest to, że mogą one wyglądać jak część strony. Mogą dziedziczyć style CSS ze strony, w tym czcionki, kolory, rozmiar tekstu itp. Iframe, OTHO musi zdefiniować ich CSS z podstawy, więc jest im ciężko mieszać się ładnie na stronie .
Ale jeszcze ważniejsze jest to, że elementy iframe muszą deklarować, jaki będzie ich rozmiar . Podczas dodawania elementu iframe do strony należy podać właściwość width i height, a jeśli nie, przeglądarka użyje domyślnych ustawień. Teraz, jeśli twój widget jest widgetem zegara, który jest wystarczająco łatwy b/c wiesz dokładnie, jaki rozmiar chcesz, ale w wielu przypadkach nie wiesz z góry, ile miejsca twój widget ma zamierza wziąć . Jeśli, na przykład, tworzysz widżet, który wyświetla listę jakiegoś rodzaju i nie wiesz, jak długo ta lista będzie miała wartość lub jak szeroki będzie każdy element. Zwykle w HTML nie jest to wielka sprawa, ponieważ HTML jest językiem opartym na deklaracjach, więc wszystko, czego potrzebujesz, to powiedzieć przeglądarce, co chcesz wyświetlić, a przeglądarka opracuje dla niej rozsądny układ, ale z iframe to nie jest tak; w przeglądarkach ifrmaes trzeba dokładnie powiedzieć, jaka jest wielkość elementu iframe, a sam go nie rozwiąże. Ten jest prawdziwym problemem dla autorów widżetów, którzy chcą używać elementów iframe - jeśli potrzebujesz zbyt dużo miejsca, strona będzie zawierała puste miejsca, a jeśli podasz zbyt mało strony, to bóg zabrania.
Mądrze wyglądają i wygrywają. Należy jednak pamiętać, że to naprawdę zależy od aplikacji widgetu. Jeśli wszystko, co chcesz zrobić, to zegar, możesz równie dobrze uzyskać wraz z iframe.
Po stronie serwera a po stronie klienta IFrmaty wymagają podania adresu URL src, aby podczas implementacji widgetu przy użyciu elementu iframe musi mieć kod po stronie serwera .Może to być zarówno ograniczenie, jak i ból głowy dla niektórych (posiadanie serwera , nazwy domeny itp., Zajmującego się obciążeniem, opłacanie rachunków sieciowych itp.) , ale dla innych jest to w rzeczywistości punkt na korzyść iframes b/c it . kompletnie napisz swoje widżety w technologiach po stronie serwera, tak abyś mógł napisać dużo kodu, a właściwie prawie wszystko przy użyciu swojej ulubionej technologii po stronie serwera, czy to asp.net, django, ror, jsp, rozpórki, perl lub inne dinozaury. Podczas implementacji wbudowanego gadżetu będziesz coraz bardziej ćwiczyć swój javascript Ninja.
Co to jest algorytm decyzyjny? Autorzy widżetów: jeśli widget może zostać zaimplementowany jako element iframe, wolą ramkę iframe po prostu dla zachowania bezpieczeństwa i zaufania użytkowników: . Jeśli widget wymaga inline (i medium pozwala, aby np. Nie iGoogle i znajomi) używali wbudowanego, ale odważą się, nie wykorzystywać zaufania użytkowników!
Instalatory widgetów: podczas instalowania widgetu na blogu nie widzisz wstążki "Bezpieczne dla użytkowników" na widżetach. Jak sprawdzić, czy widget jest bezpieczny czy nie? Są dwie alternatywy, które mogę zasugerować: 1) Ufaj sprzedawcy 2) odczytaj kod. Albo ufasz dostawcy widżetu i instalujesz go w każdym razie, albo poświęcasz czas na odczytanie jego kodu i ustalenie, czy jest ono godne zaufania, czy nie. Rzeczywistość to , że większość właścicieli witryn nie zadaje sobie trudu odczytania kodu lub nawet nie są świadomi ryzyka, na jakie narażają swoich użytkowników, a zatem dostawcy widgetów są ślepo zaufani. W wielu przypadkach nie stanowi to problemu, ponieważ blogi zwykle nie przechowują danych osobowych swoich czytelników. Podejrzewam, że rzeczy zaczną się zmieniać, gdy pojawi się kilka wysokoprofilowych exploitów (i mam nadzieję, że nigdy do tego nie dojdzie).
Użytkownicy: Użytkownicy są trzymani w ciemności. Tak jak nie ma "bezpiecznych dla użytkowników" użytkowników "wstążek na stronach instalacyjnych widgetów, nie ma witryn" bezpiecznych dla "iw zasadzie użytkownicy są trzymani w ciemności i nie mają pojęcia, , nawet jeśli mają umiejętności techniczne, niezależnie od tego, czy witryna, której używają, to: czy widgety są wbudowane czy nie i czy są złośliwe. Chociaż teoretycznie przeszkolony programista może sprawdzać kod z góry, przed uruchomieniem go w przeglądarce i utratą konta e-mailowego hakerowi, jednak nie jest to praktyczne i nie powinno być żadnego oczekiwania, że użytkownicy masowo to zrobią. . IMO to niefortunny stan i mam tylko nadzieję, że napastnicy nie znajdą sposobu na skorzystanie z tej wspaniałej, otwartej kultury widżetów w Internecie.
Happy widowni ludzie!
- niektórych platformach bloga mają nieco odmienne struktury dla widżetów i mogą czasami mieć oba wzory i wtyczek, które mogą korelują z ich funkcjonalności, ale za sprawą dyskusji tutaj będę lously używać widżet termin omówienie typu "surowego", który składa się z kodu javascript po stronie klienta: ** Chociaż w większości przypadków chcesz, aby widżety dziedziczyły style ze strony hostingu, aby wyglądały spójnie z nimi, czasami nie chcesz, aby to było Widżet dziedziczy style ze strony, więc w tym przypadku iFrames pozwala ci zacząć od zera CSS.
Jestem pewien, że wielu twórców/właścicieli witryn doceni rozwiązanie JavaScript, które mogą styl do ich potrzeb, a nie przy użyciu iframe. Gdybym miał dołączyć komponent z trzeciej strony, wolałbym to zrobić przez JavaScript, ponieważ miałbym większą kontrolę.
Jeśli chodzi o łatwość użycia, oba są podobne w prostocie, więc nie ma prawdziwego kompromisu.
Jeszcze jedna myśl, upewnij się, że uzyskasz certyfikat SSL dla każdej domeny, w której to hostujesz, i wypisz odpowiednio instrukcję include, jeśli strona jest obsługiwana przez SSL. Jeśli właściciele Twojej witryny mają powód do używania SSL, z pewnością docenią to, ponieważ Firefox i inne przeglądarki będą skarżyć się, gdy strona zostanie wyświetlona z mieszanką bezpiecznych/niezabezpieczonych treści.
Jeśli widżet może być osadzony w elemencie iframe, będzie lepiej dla funkcji frontend strony hostingowej, ponieważ elementy iframe nie blokują pobierania zawartości. Jednak, jak skomentowali inni, istnieją inne wady korzystania z elementów iframe.
Jeśli zaimplementujesz w javascript, rozważ rozwój frontend performance best practices. W szczególności powinieneś spojrzeć na Non blocking javascript loading. Analityka Google i inni dostawcy widgetów innych firm obsługują tę metodę ładowania. Pomogłoby to również, gdybyś mógł załadować javascript na dole strony.
Dlaczego nie robić obu?
wolę oferują stron osób trzecich skrypt jak:
<script type="text/javascript" src="urlToScript"></script>
plik na serwerze wygląda następująco:
document.writeln('<iframe src="pathToYourGroovyWidget"
name="MagicIframe" width="300" height="600" align="left" scrolling="no"
marginheight="0" marginwidth="0" frameborder="0"></iframe>');
UPDATE:
duża wadą stosowania iframe wskazuje to na adres URL serwera, który nie generuje "prawdziwego" łącza zwrotnego, jeśli ktoś kliknie adres URL z serwera wskazujący na serwer.
Duży plus z iframe: wszystkie CSS i JS są oddzielone od strony hosta, więc twój istniejący CSS po prostu działa. (Jeśli chcesz, aby strona hosta dopasowała zawartość do własnych potrzeb, to oczywiście minus).
Duży minus elementów pływających: mają one stałą szerokość i wysokość, a paski przewijania będą wyświetlane, jeśli zawartość jest większa .
Inną korzyścią, którą mogę zobaczyć przy użyciu elementu iFrame over JavaScript jest to, że dowolny wymagany przez niego kod CSS lub kod JavaScript jest niezależny i nie będzie kolidował ze stroną wywołującą. Oczywiście można łatwo obejść ten problem, używając nie generycznych selektorów. – Noz
w elemencie iframe można używać SLL, w javascript strona nadrzędna musi mieć zainstalowany ssl. –