Tôi phải phát triển một tiện ích sẽ được trang web của bên thứ ba sử dụng. Đây không phải là một ứng dụng được triển khai trong một trang mạng xã hội. Tôi có thể cung cấp cho các trang web một liên kết để được sử dụng như là src của một khung nội tuyến hoặc tôi có thể phát triển nó như là một yêu cầu JavaScript.Tiện ích con - Khung nội tuyến so với JavaScript
Có thể ai đó vui lòng cho tôi biết sự cân bằng giữa 2 cách tiếp cận (IFrame so với JS)?
Rất vui được biết rằng nó không được triển khai trong một trang web mạng xã hội ... mà chỉ đơn thuần là rời khỏi phần còn lại của trang web ;-)
Điều gì sẽ là hữu ích nhất phụ thuộc vào widget của bạn. IFrame và javascript thường phục vụ các mục đích khá khác nhau và có thể được trộn lẫn (ví dụ: javascript bên trong iframe hoặc javascript tạo iframe).
Tôi đã tìm kiếm về cùng một câu hỏi và tôi thấy bài viết thú vị này:
http://prettyprint.me/prettyprint.me/2009/05/30/widgets-iframe-vs-inline/
Widget là các ứng dụng web nhỏ có thể dễ dàng được thêm vào bất kỳ trang web trang. Đôi khi chúng được gọi là Tiện ích và được sử dụng rộng rãi trong việc phát triển số lượng các trang web, blog, trang web xã hội, trang chủ được cá nhân hoá như như iGoogle, Yahoo, netvibes của tôi. Trong blog này, tôi sử dụng một số tiện ích , chẳng hạn như bộ đếm RSS ở bên phải hiển thị số lượng người dùng đã đăng ký vào blog này (đừng lo lắng, nó sẽ phát triển, đó là một blog mới; ;-)). Tiện ích rất tuyệt vời theo nghĩa là chúng nhỏ chức năng có thể sử dụng lại mà ngay cả những người không lập trình có thể sử dụng để làm phong phú thêm trang web của họ.
Tôi đã viết một số tiện ích con như vậy vào thời gian cả tiện ích “thô” có thể được nhúng vào bất kỳ trang web nào cũng như tiện ích iGoogle. hạnh phúc để chia sẻ kinh nghiệm của tôi.
Là một tác giả phụ tùng, cho widget chạy về phía khách hàng (đơn giản nhúng HTML code) bạn có thể chọn văn bản widget của bạn bên trong một iframe hoặc đơn giản là nội tuyến trang và làm cho nó một phần của dom của trang lưu trữ. Phần còn lại của bài viết thảo luận về các ưu và khuyết điểm của cả hai phương pháp.
Làm thế nào về mặt kỹ thuật được thực hiện? Cách sử dụng iframe hoặc cách triển khai một tiện ích nội dòng?
Khung nội tuyến dễ thực hiện hơn một chút.Ví dụ sau hiển thị tiện ích khung nội tuyến đơn giản: http://my-great-widget.com/widgwt 'width = "100" height = "100" frameborder =' 0 '>
frameborder =' 0 ′ được sử dụng để đảm bảo ifrmae không có đường viền để trông có vẻ tự nhiên hơn trên trang. http://my-great-widget.com/widget chịu trách nhiệm phục vụ tiện ích con nội dung dưới dạng trang HTML hoàn chỉnh.
tiện ích Inline có thể trông như thế này:
chức năng createMyWidgetHtml() {return "Hello world của widget"; } document.getElementById ('myWidget'). InnerHTML = createMyWidgetHtml(); Như bạn có thể thấy, hàm createMyWidgetHtml() nó chịu trách nhiệm tạo nội dung widget thực tế và không nhất thiết phải nói chuyện với một máy chủ để thực hiện điều đó. Trong ví dụ iframe, phải có máy chủ . Trong ví dụ nội tuyến, không cần phải là máy chủ, mặc dù nếu cần, có thể lấy dữ liệu từ máy chủ, trong đó thực sự là trường hợp rất phổ biến, tiện ích con thường thực hiện mã máy chủ . Sử dụng mã phía máy chủ phương thức nội tuyến được gọi bằng phương tiện của javascript đơn giản.
Vì vậy, để tóm tắt, trong trường hợp iframe, chúng tôi chỉ cần đặt mã iframe HTML và trỏ nguồn của iframe đến vị trí cắt ngang mà thực sự phân phối nội dung của tiện ích. Trong trường hợp nội tuyến, chúng tôi tạo nội dung cục bộ bằng javascript. Tất nhiên, bạn có thể kết hợp sử dụng iframe iframe với javascript cũng như sử dụng phương thức nội tuyến với các cuộc gọi phía máy chủ, bạn không bị giới hạn bởi điều đó, nhưng đường dẫn bắt đầu khác biệt.
Vì vậy, thỏa thuận lớn là gì? Có gì khác biệt? Có một số khác biệt quan trọng của , do đó, ở đây bắt đầu phần thú vị của bài đăng .
Bảo mật. Tiện ích iFrame an toàn hơn.
Những rủi ro nào mà các tiện ích có thể áp dụng và ai thực sự bị rủi ro? Người dùng của trang web và danh tiếng của trang web có nguy cơ.
Với tiện ích nội tuyến, trình duyệt cho rằng nguồn của tiện ích mã mã đến từ trang web lưu trữ. Giả sử bạn đang xem ứng dụng thư yêu thích của bạn http://my-wonderful-email.com và ứng dụng thư này đã cài đặt tiện ích hiển thị đồng hồ từ http://great-clock-widgets.com/. Nếu các tiện ích con đó được triển khai dưới dạng tiện ích nội tuyến trình duyệt cho rằng mã của tiện ích có nguồn gốc tại my-wonderful-email.com và không phải tại great-clock-widgets.com và do đó, nó sẽ để mã của tiện ích cuối cùng có quyền truy cập cho các cookie thuộc sở hữu của my-wonderful-email.com và tác giả độc ác của tiện ích con sẽ lấy cắp email của bạn. Điều quan trọng là phải nhận ra rằng các trình duyệt không quan tâm đến vị trí của tệp javascript được lưu trữ; miễn là mã chạy trên cùng một khung , trình duyệt coi tất cả mã là originationg ở miền của khung. Vì vậy, bạn là người dùng bị tổn thương do mất quyền kiểm soát email của mình tài khoản và email tuyệt vời của tôi bị tổn thương do mất danh tiếng của mình.
Nếu cùng một đồng hồ đã có thể nhận được thực hiện bên trong một iframe và nguồn iframe là khác nhau từ mã nguồn trang web (đó là trường hợp phổ biến , ví dụ như mã nguồn trang web là my-wonderful-email.com và tiện ích nguồn là great-clock-widgets.com) thì trình duyệt sẽ không cho phép tiện ích đồng hồ truy cập vào cookie của trang, cũng như không cho phép truy cập vào bất kỳ phần nào khác của tài liệu lưu trữ, bao gồm cả trang chủ lưu trữ . Đó là cách an toàn hơn. Trên thực tế, trang chủ cá nhân chẳng hạn như iGoogle thậm chí không cho phép tiện ích nội tuyến, chỉ cho phép các khung nội tuyến tiện ích. (tiện ích nội tuyến chỉ được phép trong các trường hợp hiếm hoi, chỉ sau khi nhóm iGoogle kiểm tra kỹ lưỡng để đảm bảo chúng không độc hại)
Tóm lại, tiện ích khung nội tuyến an toàn hơn. Tuy nhiên, chúng cũng là cách hạn chế hơn về chức năng. Tiếp theo, chúng tôi sẽ thảo luận về những gì bạn bị mất trong chức năng .
Nhìn và cảm nhận Trong các tiện ích trực tuyến chiến đấu giao diện (thường **) giành chiến thắng. Những điều tốt đẹp về họ là họ có thể được thực hiện để trông giống như một phần của trang. Họ có thể kế thừa các kiểu CSS từ trang, bao gồm phông chữ, màu sắc, kích thước văn bản, v.v. Iframe, OTHO phải xác định CSS của chúng từ căn cứ nên rất khó để chúng có thể pha trộn độc đáo trong trang .
Nhưng điều quan trọng hơn nữa là iframe phải khai báo kích thước của chúng là gì. Khi thêm iframe vào trang, bạn phải bao gồm thuộc tính chiều rộng và chiều cao và nếu không, trình duyệt sẽ sử dụng một số cài đặt mặc định. Bây giờ, nếu tiện ích con của bạn là tiện ích con đồng hồ là đủ dễ dàng b/c, bạn biết rõ kích cỡ bạn muốn, nhưng trong nhiều trường hợp bạn không biết trước thời gian mà tiện ích của bạn là sẽ mất . Ví dụ: nếu bạn đang cấp quyền cho một tiện ích hiển thị danh sách một số loại và bạn không biết danh sách này sẽ dài đến mức nào hoặc độ rộng của từng mục. Thông thường trong HTML, đây không phải là giao dịch lớn vì HTML là ngôn ngữ dựa trên khai báo vì vậy tất cả những gì bạn cần cần làm là cho trình duyệt biết bạn muốn hiển thị gì và trình duyệt sẽ tìm ra bố cục hợp lý cho nó. không phải là trường hợp; với trình duyệt ifrmaes yêu cầu bạn cho biết chính xác kích thước iframe là gì và nó sẽ không tự tìm ra. là một vấn đề thực sự đối với các tác giả tiện ích muốn sử dụng iframe - nếu bạn yêu cầu quá nhiều không gian, trang sẽ có khoảng trống trong đó và nếu bạn chỉ định quá ít trang sẽ có thanh cuộn trong đó.
Xem và cảm nhận khôn ngoan, chiến thắng nội tuyến. Nhưng lưu ý rằng điều này thực sự phụ thuộc vào ứng dụng tiện ích của bạn. Nếu tất cả những gì bạn muốn làm là đồng hồ, bạn cũng có thể nhận được cùng với iframe.
Phía máy chủ so với phía máy khách IFrmaes yêu cầu bạn chỉ định URL src để khi triển khai tiện ích con bằng iframe, bạn phải có mã máy chủ .Điều này có thể là một hạn chế và đau đầu cho một số người (sở hữu máy chủ , tên miền, vv, xử lý tải, thanh toán hóa đơn mạng, v.v.) nhưng đối với những người khác, đây thực sự là điểm ưu tiên của iframes b/c nó hoàn toàn viết các widget của bạn trong các công nghệ phía máy chủ, để bạn có thể viết nhiều mã và thực sự gần như tất cả nó bằng cách sử dụng công nghệ phụ của máy chủ yêu thích của bạn cho dù đó là asp.net, django, ror, jsp, struts, perl hoặc khủng long khác. Khi triển khai một tiện ích nội tuyến , bạn sẽ thấy mình ngày càng thực hành Ninja javascript của mình.
Thuật toán quyết định là gì? Tác giả tiện ích: Nếu tiện ích có thể được triển khai dưới dạng khung nội tuyến, hãy chọn Khung nội tuyến đơn giản để giữ bảo mật và tin cậy của người dùng . Nếu tiện ích con yêu cầu nội tuyến (và phương tiện cho phép, ví dụ: không phải iGoogle và bạn bè) sử dụng nội tuyến nhưng dám không khai thác sự tin tưởng của người dùng!
Trình cài đặt tiện ích con: Khi cài đặt tiện ích con trong blog của bạn, bạn sẽ không thấy dải băng “an toàn cho người dùng” trên các tiện ích. Làm cách nào để bạn biết được tiện ích có an toàn hay không? Có hai lựa chọn thay thế tôi có thể đề xuất: 1) tin tưởng nhà cung cấp 2) đọc mã. Hoặc bạn tin tưởng các widget nhà cung cấp và cài đặt nó anyway hoặc bạn dành thời gian để đọc mã số của nó và xác định chính mình cho dù đó là đáng tin cậy hay không. Thực tế là rằng hầu hết chủ sở hữu trang web không bận tâm đọc mã hoặc thậm chí không nhận biết được về nguy cơ họ đang đưa người dùng của họ vào và do đó, nhà cung cấp tiện ích được tin tưởng một cách mù quáng. Trong nhiều trường hợp, đây không phải là vấn đề vì blog thường không giữ thông tin cá nhân về người đọc của họ. Tôi nghi ngờ mọi thứ sẽ bắt đầu thay đổi sau khi có ít khai thác hồ sơ cao (và tôi hy vọng nó sẽ không bao giờ liên quan đến nó).
Người dùng: Sử dụng được giữ trong bóng tối. Cũng giống như không có dải “an toàn cho người dùng” trên chủ sở hữu trang web tiện ích cài đặt, không có trang web “an toàn cho sử dụng” và người dùng cơ bản được giữ trong bóng tối và không có ý tưởng, ngay cả khi họ có kỹ năng kỹ thuật, có hay không trang web mà họ đang sử dụng chứa tiện ích con, cho dù tiện ích có nội tuyến hay không và cho dù chúng có độc hại hay không. Mặc dù về mặt lý thuyết, một nhà phát triển được đào tạo có thể kiểm tra mã trước, trước khi chạy mã trong trình duyệt của mình và mất tài khoản email của cô ấy cho một hacker, tuy nhiên điều này là không thực tế và ở đó . IMO đây là một điều kiện không may và tôi chỉ hy vọng những kẻ tấn công sẽ không tìm thấy cách nào lợi dụng điều đó và diệt vong văn hóa tiện ích mở tuyệt vời trên web.
Chúc mừng những người tiện ích!
- Một số blog platform có một cấu trúc hơi khác nhau cho các widget và đôi khi họ có thể có cả widget và plugin có thể tương quan về tính năng của họ, nhưng đối với các vấn đề của cuộc thảo luận ở đây tôi sẽ lously sử dụng widget hạn để thảo luận về loại "thô" mà bao gồm mã javascript phía máy khách ** Mặc dù trong hầu hết các trường hợp, bạn muốn các tiện ích kế thừa kiểu từ trang lưu trữ để làm cho chúng trông phù hợp với nó, đôi khi bạn thực sự không muốn các widget để kế thừa phong cách từ trang, vì vậy trong trường hợp này iFrames cho phép bạn bắt đầu CSS của bạn từ đầu.
Tôi chắc chắn nhiều nhà phát triển/chủ sở hữu trang web sẽ đánh giá cao một giải pháp javascript rằng họ có thể tạo kiểu cho nhu cầu của họ hơn là sử dụng một iframe. Nếu tôi định đưa một thành phần từ một bên thứ ba, tôi thà làm điều đó thông qua Javascript vì tôi sẽ có nhiều quyền kiểm soát hơn.
Dễ sử dụng, cả hai đều tương tự nhau về tính đơn giản, vì vậy không có sự cân bằng thực sự ở đó.
Một ý nghĩ khác, hãy đảm bảo bạn nhận được chứng chỉ SSL cho bất kỳ miền nào bạn đang lưu trữ và viết câu lệnh bao gồm cho phù hợp nếu trang được phân phối qua SSL. Trong trường hợp chủ sở hữu trang web của bạn có lý do để sử dụng SSL, họ chắc chắn sẽ đánh giá cao điều này, bởi vì Firefox và các trình duyệt khác sẽ khiếu nại khi một trang được phân phối với nội dung an toàn/không an toàn.
Nếu tiện ích có thể được nhúng trong khung nội tuyến, sẽ tốt hơn cho hiệu suất giao diện người dùng của trang web lưu trữ vì iframe không chặn tải xuống nội dung. Tuy nhiên, như những người khác đã nhận xét có những hạn chế khác để sử dụng iframe.
Nếu bạn thực hiện trong javascript, vui lòng xem xét frontend performance best practices khi phát triển. Đặc biệt, bạn nên xem Non blocking javascript loading. Google Analytics và các nhà cung cấp tiện ích con bên thứ 3 khác hỗ trợ phương thức tải này. Nó cũng sẽ giúp đỡ nếu bạn có thể tải javascript ở dưới cùng của trang.
Tại sao không thực hiện cả hai?
tôi thích để cung cấp các trang web của bên thứ ba một kịch bản như:
<script type="text/javascript" src="urlToScript"></script>
tập tin trên máy chủ của bạn trông giống như:
document.writeln('<iframe src="pathToYourGroovyWidget"
name="MagicIframe" width="300" height="600" align="left" scrolling="no"
marginheight="0" marginwidth="0" frameborder="0"></iframe>');
UPDATE:
những bất lợi lớn của việc sử dụng một khung nội tuyến trỏ đến một url trên máy chủ của bạn là bạn không tạo ra một backlink "thực" nếu ai đó nhấp vào một url từ máy chủ của bạn trỏ đến máy chủ của bạn.
Điểm cộng lớn của iframe: tất cả CSS và JS được tách ra khỏi trang lưu trữ, vì vậy CSS hiện tại của bạn chỉ hoạt động. (Nếu bạn muốn trang web lưu trữ tạo kiểu cho nội dung phù hợp, thì đó là dấu trừ.)
Dấu trừ lớn của iframe: chúng có chiều rộng và chiều cao cố định và thanh cuộn sẽ xuất hiện nếu nội dung của bạn lớn hơn .
Một lợi ích khác mà tôi có thể thấy khi sử dụng iFrame trên JavaScript là bất kỳ CSS hoặc Javascript nào yêu cầu sẽ được tự chứa và sẽ không can thiệp vào trang web gọi điện. Tất nhiên bạn có thể dễ dàng giải quyết vấn đề này bằng cách sử dụng bộ chọn không chung chung. – Noz
trong iframe bạn có thể sử dụng SLL, trong javascript trang web mẹ phải được cài đặt ssl. –