Iframes एक भयानक विचार हैं?

मैं एक विजेट बना रहा हूं, और मैं इसके अंदर सामग्री प्रस्तुत करने के लिए iframes का उपयोग कर रहा हूं। किसी बिंदु पर, मैं तीसरे पक्ष के एचटीएमएल और जेएस की सेवा करना शुरू कर सकता हूं, इसलिए मैंने सोचा कि iframes एक अच्छा विचार होगा।

यह विजेट जावास्क्रिप्ट को थोड़ा और जटिल बनाता है, और मुझे चिंता है कि यह सबसे अच्छा कार्यान्वयन नहीं हो सकता है।

क्या आपका कोई सुझाव है? यह सुनकर एक बड़ी मदद होगी कि अन्य लोग iframes के बारे में क्या सोचते हैं।

0

15 उत्तर

हाल ही में एक चीज मैंने खोजी है कि iframes के अंदर एम्बेडेड .aspx पेजों में कभी-कभी कुकीज़ खोने में समस्याएं होती हैं, जिसके कारण मैं उस एप्लिकेशन में खो गया सत्र राज्य खो देता था।

मेरे लिए, यह एक परिदृश्य में था जहां एक अलग विकास की दुकान मेरे अपने पृष्ठ में मेरे .aspx पृष्ठों में से एक का उपभोग कर रही थी। इसका मतलब है कि हम अलग-अलग सर्वर पर थे, जो मुख्य हो सकते हैं या नहीं भी हो सकते हैं।

जाहिर है यह मूल पृष्ठ के कारण बच्चे पृष्ठ के लिए कुकीज को अस्वीकार कर रहा है ... जैसा कि सत्र कुकी जाता है, इसलिए सत्र चला जाता है।

The specific mechanics of how this works are a little involved: More Details

इस समस्या ने फ़ायरफ़ॉक्स को प्रभावित नहीं किया, लेकिन यह आईई 7 में दिखाया गया था और यह कुछ घंटों के लिए एक असली रहस्य था।

इसके अलावा, मुझे एक बिंदु पर उपरोक्त लिंक से संबंधित लेख का खंडन करना होगा। लेख कहता है कि यदि आप युक्त पेज भी एक .aspx है तो आपको यह नहीं मिलता है ... इस मामले में, यह सच नहीं था क्योंकि दोनों पृष्ठ .aspx थे।

इस स्थिति के बारे में लेख कहता है कि बाकी सब कुछ पर कुछ संदेह है, लेकिन इससे एक संकल्प हुआ, इसलिए यह कुछ भी है।

जैसा कि आलेख ने सुझाव दिया है, मैंने निम्नलिखित कोड डाला है, जो पेज के इनिट इवेंट में एक पी 3 पी (गोपनीयता प्राथमिकता प्रोजेक्ट - मैंने कभी इसके बारे में कभी नहीं सुना है) इंजेक्शन दिया है:

HttpContext.Current.Response.AddHeader("p3p", "CP=\""IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT\""")

... और यह समस्या ठीक हो गई।

0
जोड़ा

व्यक्तिगत रूप से, मैं इसे से बच सकता हूं यदि आप बहुत अधिक परेशानी के बिना कर सकते हैं। जावास्क्रिप्ट का उपयोग करना (या AJAX यदि आपको गतिशील रूप से लोड करने की आवश्यकता है), तो आप आसानी से केवल एक div का उपयोग कर सकते हैं और सामग्री को आवश्यकतानुसार बदल सकते हैं - कुछ मामलों में यह आपको अधिक लचीलापन देगा और आपके जेएस को सरल बना देगा, खासकर यदि बहुत कुछ है अपने विजेट और शेष पृष्ठ के बीच बातचीत का।

उस ने कहा, मैं दोनों विकल्पों की जांच करता हूं, और यदि जेएस पथ बहुत मुश्किल या जटिल लगता है, तो बस iframes के साथ जाओ।

0
जोड़ा

अतिप्रवाह सीएसएस संपत्ति का उपयोग करना एक अच्छा विकल्प है। डिफ़ॉल्ट मान दिखाई देता है लेकिन आप इसे छुपा, स्क्रॉल या ऑटो पर सेट कर सकते हैं। मैं आपके मामले में ऑटो का उपयोग करूंगा। यदि आपकी सामग्री बहुत बड़ी हो जाती है तो ऐसा लगता है कि आपके पास आईफ्रेम है लेकिन यह अभी भी पृष्ठ पर सही है।

see: overflow property

0
जोड़ा

तकनीकी रूप से iFrame के साथ कुछ भी गलत नहीं है कि विकल्प के साथ। लेकिन अर्थात्, बुराई है।

वेब HTTP पर आधारित है, एक प्रोटोकॉल जो कहता है कि दिया गया यूआरएल हमेशा एक अद्वितीय रिसोर्स का नेतृत्व करेगा।

IFrame का उपयोग करके, आप बस उन सभी के लिए एक यूआरएल के पीछे एक वेब पेजों में पिघल गए कई संसाधनों की सेवा करते हैं। यदि आपको चिंता है कि वेब कैसे बढ़ना चाहिए, तो यह परेशानी है। खोज इंजन रोबोट के लिए और भी, यह मुश्किल है।

0
जोड़ा

निर्भर करता है कि विजेट क्या करता है। इफ्रेम के पास उनकी जगह है, लेकिन वे कुछ लेआउट सिरदर्द का कारण बनते हैं (अपने जेएस को अधिक जटिल बनाने का उल्लेख नहीं करते हैं) इसलिए अधिकांश लोग पूरी तरह से जरूरी होने तक उनसे बचते हैं ..

0
जोड़ा

उनके साथ केवल एक "वास्तव में खराब" चीज है जिसे मैं जानता हूं।

यदि आपकी तीसरी पार्टी कुछ जावास्क्रिप्ट करता है, तो वह अपने डीओएम को बहुत जल्दी संशोधित करने का प्रयास करता है ... आईई 6 और आईई 7 ओह को इतना असहाय फेंक देगा " ऑपरेशन निरस्त " त्रुटि, फिर न केवल खाली iframe, लेकिन पूरे आस-पास के पृष्ठ । (उदा। आपकी साइट नीचे दिखाई देती है)

यह आईई 8 में तय नहीं है, लेकिन दुर्घटना बेहतर संभाला जाता है।

0
जोड़ा

फ्रेम की तरह iframes, हाथ में काम के लिए उपयोग करने के लिए सिर्फ नियंत्रण हैं। इस प्रकार, यह न तो अच्छा है और न ही बुरा है, बल्कि हाथ और ग्राहक की आवश्यकताओं के आधार पर अच्छा या बुरा हो सकता है। जहां तक ​​मुझे पता है, सभी आधुनिक ब्राउज़र (और गैर-लिनक्स उपयोगकर्ता) किसी समस्या के बिना iframes को "देख और उपभोग" करने में सक्षम होंगे।

0
जोड़ा

नहीं, iframes के साथ कुछ भी गलत नहीं है। अगर आप तीसरे पक्ष की सामग्री की सेवा शुरू करने जा रहे हैं तो इफ्रेम शायद एक बेहतर विचार है।

आने वाले एचटीएमएल 5 spec भी इस तरह की स्थितियों के लिए iframes में और अधिक सुरक्षा सुविधाओं का निर्माण करने की योजना है, तो मैं अब भी उनका उपयोग करने के लिए अच्छा अभ्यास मानता हूं।

0
जोड़ा
मैं यहां +1 करता हूं - बेशक, केवल यह सुनिश्चित करना है कि उपयोग वास्तव में आदर्श है (यानी केवल आवश्यक डेटा को पकड़ने के लिए अजाक्स का उपयोग करने के बजाय - सर्वर हमेशा "तृतीय-पक्ष सामग्री" को पकड़ और पार्स कर सकता है और हो सकता है आउट ऑफ़ बैंड कॉल के माध्यम से पुनर्प्राप्त)।
जोड़ा लेखक Jason Bunting, स्रोत

जरूरी नहीं है, जब तक आईफ्रेम के भीतर की सामग्री अनुमानित है।

0
जोड़ा

XMLHTTPRequest का व्यापक रूप से उपयोग करने से पहले, लोग पूर्ण पृष्ठ रीफ्रेश किए बिना गतिशील फैशन में सामग्री को प्रस्तुत करने के लिए जावास्क्रिप्ट और आईफ्रेम के संयोजन का उपयोग कर रहे थे।

इस तरह के विकासशील साइटों के बारे में बहुत सारी जानकारी है, इसलिए आपके पास हिट होने की संभावना वाले कई स्नैग के लिए कामकाज खोजने का अपेक्षाकृत आसान समय होना चाहिए।

एक चीज जिसे मैंने दर्द पाया है, आईफ्रेम में जावास्क्रिप्ट का क्रॉस-डोमेन उपयोग है। यदि आईफ्रेम में एम्बेड किया गया पृष्ठ "पैरेंट" पृष्ठ की तुलना में किसी भिन्न डोमेन से है, तो ब्राउज़र के पास आपको दूसरे से एक तक पहुंचने के विरुद्ध सुरक्षा प्रतिबंध हैं। चाल दोनों पृष्ठों के घोषित करने के लिए है

document.domain = 'somedomain.com';

इस तरह के कामकाज के बारे में वेब पर बहुत सी चीजें हैं।

सौभाग्य!

0
जोड़ा
मेरा मानना ​​है कि वे केवल दस्तावेज़ .डोमेन को उच्च स्तर के डोमेन के रूप में बदल सकते हैं - यानी www.acme.com डोमेन को acme.com में बदल सकता है, लेकिन google.com पर नहीं। इस प्रकार यह केवल एक डोमेन के सबडोमेन में संचार करने में मदद करता है। (मैं गलत हो सकता था लेकिन मुझे यही याद है)
जोड़ा लेखक Josh, स्रोत
@ जोश - आपका सही है, document.domain केवल उसी पेरेंट डोमेन पर पृष्ठों के लिए काम करेगा लेकिन अलग-अलग सबडोमेन।
जोड़ा लेखक Livingston Samuel, स्रोत
@ जोश आप सही हैं, लेकिन आप हमेशा window.location.href का उपयोग कर सकते हैं।
जोड़ा लेखक nyuszika7h, स्रोत

मेरे अनुभव में, iframes या तो हैक्स या टाइम-सेवर हैं - सुनिश्चित करें कि यदि आप उनका उपयोग कर रहे हैं तो वे उन कारणों से निष्पक्ष हैं। यदि आपके पास सामग्री पर नियंत्रण है (या मिररिंग या स्क्रैपिंग के माध्यम से नियंत्रण प्राप्त कर सकते हैं) तो आपको AJAX या सर्वर-साइड का उपयोग करने पर विचार करना चाहिए, बाहरी डेटा को खींचने और पृष्ठ से इसे धक्का देने के लिए - इसमें अधिक लचीला होना समाप्त हो जाएगा, और अधिक मजबूत, और अंत में प्रबंधन करने में आसान है।

0
जोड़ा

मैं बहुमत से असहमत होने जा रहा हूं और कहता हूं कि हाँ, iframes एक बिल्कुल भयानक विचार हैं। कोई भी जिसने वेब डिज़ाइन समुदाय के भीतर कुछ समय के लिए काम किया है, इस बात से सहमत होगा कि iframes शुद्ध बुराई हैं और जब तक ABSOLUTELY आवश्यक न हो, तब से बचा जाना चाहिए।

यह मानने के मेरे कारण हैं कि वे बुरे हैं क्योंकि वे एक वेब पेज के नेविगेशन पैटर्न को तोड़ते हैं। एक आईफ्रेम का उपयोग करके आप ब्राउज़र पर बैक और फॉरवर्ड बटन प्रभावी ढंग से तोड़ सकते हैं और अपने उपयोगकर्ताओं को भ्रमित कर सकते हैं। यह HTTP प्रोटोकॉल के पीछे पूरे विचार को तोड़ देता है; कि एक यूआरएल हमेशा एक अद्वितीय स्थान की ओर ले जाएगा। अगर आईफ्रेम एक घोड़ा था तो वह बहुत पहले सेवानिवृत्त हो गया होगा। गतिशील रूप से सामग्री की सेवा करने के अन्य तरीके हैं और इनका उपयोग इनका उपयोग किया जाना चाहिए।

यदि आप एक विजेट बना रहे हैं तो iframes का उपयोग करने के साथ तत्काल चिंताओं गायब हो जाते हैं (खोज इंजन के लिए बुरा, बुकमार्किंग के लिए बुरा, आदि), लेकिन किसी भी तरह की सामग्री गतिशील रूप से या यहां तक ​​कि एक नई विंडो में भी बेहतर सेवा दी जाएगी एक आईफ्रेम के बजाय।

0
जोड़ा
-1 जैसा कि एक और जवाब में कहा गया है: "यह न तो अच्छा है और न ही बुरा है, बल्कि काम पर आधारित अच्छा या बुरा हो सकता है"। साथ ही, बैक और फॉरवर्ड बटन वाला मुद्दा आईफ्रेम के लिए विशिष्ट नहीं है, यह अन्य गतिशील सामग्री के साथ भी होता है।
जोड़ा लेखक Christophe, स्रोत

पुन: "HTTP प्रोटोकॉल के पीछे पूरा विचार; कि एक यूआरएल हमेशा एक अद्वितीय स्थान का नेतृत्व करेगा"

मैं सुरक्षा और स्केलिबिलिटी के लिए एक ही यूआरएल से अपने पूरे सीएमएस की सेवा करता हूं (जीईटी पैरामीटर के बजाय ज्यादातर POST का उपयोग करके)। मैं प्रमाणीकरण के बिना सुरक्षित सामग्री को नहीं देखना चाहता, और एक प्रेषण प्रणाली मेरे लिए विकास को आसान बनाती है क्योंकि मुझे हर नए पृष्ठ के लिए प्रमाणीकरण के बारे में चिंता करने की ज़रूरत नहीं है।

इसके अलावा, कुछ अनुप्रयोगों के लिए एसईओ लागू नहीं है (जैसे वेब-आधारित ईआरपी के लिए)।

मैं PHP उत्पन्न असेंबली पेड़ से सामग्री की सेवा के लिए iFrame का उपयोग करता हूं। मैं नहीं चाहता कि पेड़ (और नोड दृश्यता) ताज़ा हो जब भी उपयोगकर्ता किसी भाग/असेंबली के लिए विवरण देखना चाहता हो।

0
जोड़ा
मुझे खुशी है कि मैं आपके उपयोगकर्ताओं में से एक नहीं हूं! ( सभी पर बुकमार्क नहीं कर सकता!)
जोड़ा लेखक SamB, स्रोत

कई iframes के साथ उपयोगिता और पहुंच योग्यता समस्याएं । कुछ ब्राउज़र और स्क्रीनreader iframes प्रदर्शित नहीं कर सकते हैं, इसलिए आपको वैकल्पिक सामग्री प्रदान करनी चाहिए:

<iframe src="content.html">
    
This content will only be displayed by browsers that do not support iframes. You should provide a link to the content, or in your case an alternative way to use your widget.

</iframe>

यदि आप तीसरे पक्ष की सामग्री की सेवा करना शुरू करते हैं, तो आपको लोडिंग समाप्त होने के बाद आईफ्रेम हथियाने के फोकस के लिए देखना चाहिए। नियमित उपयोगकर्ताओं के लिए मामूली परेशानी होने पर, यह स्क्रीनreaders के साथ ब्राउज़ करने वाले उपयोगकर्ताओं के लिए बहुत भ्रमित हो सकता है।

0
जोड़ा

आईफ्रेम के साथ एक महत्वपूर्ण मुद्दा है जो शायद ही कभी उल्लेख करता है लेकिन मेरे द्वारा भरने वाली बग कौन सा है।

हमारे सहयोगी के पास जीवनभर का काम गतिशील रूप से बदलते डेटाबेस में निवेश किया जाता है जिसे हमने Google डॉक्स स्प्रैडशीट में लोड किया है जिसे हम कई सहायक सामग्री के साथ हमारी साइट पर प्रदर्शित करते हैं।

किसी को अपने पृष्ठ स्रोत से iframe कोड को पकड़ने और इसे अपने पृष्ठ पर खींचने से रोकने के लिए बिल्कुल कुछ भी नहीं है। अब वे हमारे सभी डेटा प्राप्त कर रहे हैं, कुछ मिनट पहले तक ताज़ा हो गए, बिल्कुल कुछ भी नहीं के लिए अपने पृष्ठ पर सेवा की।

यदि एक Google iframe किसी विशिष्ट डोमेन से बंधे जा सकते हैं, तो वह इसे अपने ट्रैक में रोक देगा।

कोई विचार, उज्ज्वल स्पार्क?

0
जोड़ा
यह काफी पुराना है लेकिन यदि आप अभी भी समाधान ढूंढ रहे हैं तो मैं आईफ़्रेम लोड करने वाले को प्रतिबंधित करने के लिए X-Frame-Option शीर्षलेख का उपयोग करने के बारे में सोच सकता हूं। अब, आप Google डॉक्स यूआरएल पर इस हेडर को स्पष्ट रूप से लागू नहीं कर सकते क्योंकि आप इसे नियंत्रित नहीं करते हैं। लेकिन आप क्या कर सकते हैं, सीधे Google डॉक्स यूआरएल का उपयोग करने के बजाय, अपने यूआरएल के साथ आओ जो एक सर्वर पक्ष Google डॉक्स यूआरएल पर रीडायरेक्ट करता है। और फिर आप अपने स्वयं के यूआरएल में उचित <�कोड> एक्स-फ़्रेम-विकल्प शीर्षलेख लागू कर सकते हैं
जोड़ा लेखक Suhas, स्रोत