به کار نبردن ob_start() و ob_end_flush()

[qqq2qqq]

سلام می خوام بدونم اگه این 2 تا دستور رو تو برنامه به کار نبرم مشکلی واسه برنامه پیش میاد یا نه؟

[MMSHFE]

بستگی به نوع طراحی شما داره که نیازمند بافر خروجی هست یا نه؟

[qqq2qqq]

خب چه موقعی نیاز به بافر خروجی داره من همیشه واسه همه فرمها از این 2 دستور استفاده می کنم

[ravand]

ميشه در مورد اين دو دستور توضيح بديد؟

[tux-world]

يه موردش كه استفاده كردم واسه لاگ آوت و تعيين هدر براي رفتن به صفحه اصلي بود كه با اين دستور مشكلم رفع شد ميگفت كه هدر ارسال شده و خطا ميگرفت.

[idocsidocs]

از این دستور بیشتر برای کش کردن کوئری ها استفاده می کنم.

[MMSHFE]

کلاً هر زمان که نیاز داشتین چیزی برای مرورگر ارسال نشه، میتونید بافر خروجی رو فعال کنید و هر موقع کارتون با بافر تمام شد، میتونید اون رو دریافت کرده و برای مرورگر بفرستید. این استفاده، محدود به مشکلاتی که در کار با Session و Cookie و توابع Header و... پیش میاد محدود نمیشه و برای مثال، اگه تابع خاصی هست که خروجی رو مستقیماً توی صفحه قرار میده (مثل var_dump) و شما میخواین اون رو توی یک متغیر داشته باشین، میتونید از بافر خروجی استفاده کنید، به این شکل که قبل از استفاده از اون تابع، بافر رو فعال میکنید و بعد از اجرا، محتوای بافر رو توی متغیر میریزین و بعد، بافر رو خالی میکنید. موفق باشید.

[manager_66]

این روش ، یعنی بافر کردن ورودی و فرستادن اون به خروجی مزیت خاصی هم داره ؟ یعنی سرعت کار رو بالا میبره یا نه؟ مثلا محتویات یک صفحمون چند تا table و ... هست . اگه همشون رو بافر کنیم بعد یهو بفرستیم تو یک متغیر بعد متغیر رو echo کنیم خوبه یا نه؟ متشکرم

[nekooee]

من تمام سایتهای ایرانی و خارجی رو خوندم ولی اصلا نتونستم درک کنم این کار به چه درد میخوره که یک چیز رو بافر کنیم. چون نتیجه در هر حالت یکی میشه. جز موردی که دوستان میگن خطا میگیرن! که من هنوز جایی خطا هم نگرفتم. مثلا تو یک مثال ، کد دایرکت کردن کسایی که وارد لینک اشتباه میشن به ایندکس بین ob_start() و ob_end_flush(); قرار گرفته و من میدونم که بدون این هم دایرکت صورت میگیره. پس چه نیازی به این کد هست؟
در ضمن من وقتی این کد رو با ob_start() شروع میکنم یعنی اطلاعات تا زمانی که من بافر رو با ob_end_flush(); آزاد نکنم نباید چاپ بشه. اما بدون اینکه من از ob_end_flush(); استفاده کنم بازم اطلاعات چاپ میشه! پس چجوری بافر میشه که بازم اطلاعات چاپ میشه؟

مثالهایی هم که خود manual زده خیلی پیچیده هست و من کدهای وسطش نمیفهمم چی هست که بخوام درست عملکرد این رو تجزیه تحلیل کنم

[Unique]

کد دایرکت کردن کسایی که وارد لینک اشتباه میشن به ایندکس بین ob_start() و ob_end_flush(); قرار گرفته و من میدونم که بدون این هم دایرکت صورت میگیره. پس چه نیازی به این کد هست؟
زماین که دارین header به سمت کلاینت ارسال میکنید اگه یک کاراکتر هم قبلش چاپ کرده باشین خطای headers already sent میگرید ! حالا header هی چی باشه ! season و cookie و Location و هر header دیگه ای خطا میگیرید ! اما چون عموما این دستورات قبل از ارسال کاراکتر ها استفاده میشه مگه اینکه نوع کدنویسی شخص بد باشه ! خطایی دریافت نمیشه ! و استفاده ازش هم بیهوده هستش. اما حالا فکر کنین ما میخواهیم خروجی که دراین تولید میکنیم را برای cache کردن و عدم process مجدد اسکریپت روی hard ذخیره کنیم ! حالا مجبوریم ob_start کنیم و در پایان ob_get_contents و وقتی میخوایم اطلاعات را بفرستیم به مرورگر هم ob_end_flush این همون کاری هست که دوستمون گفت :

از این دستور بیشتر برای کش کردن کوئری ها استفاده می کنم.

[nekooee]

خیلی ممنون که پاسخ دادید.
در مورد اول که گفتین حتی اگر یک کارکتر قبلش چاپ بشه دیگه خطا میده. بله تست کردم و همینطور بود. اما خوب در صفحه ای که فقط هدر هست که دایرکت بشه دیگه نیازی نیست اما دوستمون برای این صفحه خالی با یک هدر هم استفاده کردند که به صحبت شما بیمورد هست دیگه.

در مورد دوم من هر جور تست کردم که اطلاعات فقط بافر بشه و چاپ نشه نتونستم. میشه یک کد ساده که یک دستور مثل چاپ یک عبارت رو بافر کنه و روی هارد ذخیره کنه برای بعدا بنویسید؟
بازم ممنون

[Unique]

در مورد دوم من هر جور تست کردم که اطلاعات فقط بافر بشه و چاپ نشه نتونستم
تا اونجا که من سواد دارم در پایان اجرای اسکریپت هر چیزی توی Internal buffer هست ارسال میشه و دلیلی هم نیست که ارسال نشه ! اگه میخوان مطمئن بشین مثلا :


ob_start();
echo "this ia a test";
ob_end_clean();
// output is nothing

توی این مثال اگه ob_start عمل نمیکرد باید خروجی را ببینید ! برای اینکه مطمپن بشین خروجی توی buffer ذخیره میشه از آرگمان اول که یک callback function هست استفاده کنید ، در این حالت وقتی ob_end_flush میکنید مقادیر میره توی callback و بعدش چاپ میشه ! مثال خود سایت php.net :


function callback($buffer)
{
// replace all the apples with oranges
return (str_replace("apples", "oranges", $buffer));
}

ob_start("callback");

?>
<html>
<body>
<p>It's like comparing apples to oranges.</p>
</body>
</html>
<?php

ob_end_flush();

یک مورد دیگه هم که شاید کمتر دوستان بدونند اینه که ob_start به صورت stackable هست و اگه به صورت nested (تو در تو) صدا زده بشه ! جدا جدا عمل میشه و مثل حلقه های تو در تو میتونید با ob_end_flush() هر ob_start را ببندین !

[eshpilen]

اما چون عموما این دستورات قبل از ارسال کاراکتر ها استفاده میشه مگه اینکه نوع کدنویسی شخص بد باشه !
فکر نمیکنم ربطی به بد یا خوب بودن کدنویسی داشته باشه.
دلیل و سند روشن و محکمی بر این هست؟
درسته شاید در بیشتر موارد یا حتی بگیم تمام موارد بشه طوری کد نوشت و روشهایی بکار برد که برنامه تمام هدرهاش رو قبل از هر نوع خروجی دیگری ارسال کنه، ولی این دلیل نمیشه بگیم اگر کسی غیر از این عمل کرد بد کدنویسی کرده. تازه اون روش اول ممکنه خودش باعث حجم و پیچیدگی غیرضروری کد و افزایش احتمال باگ بشه.
باز اینم که بیشتر افراد ناشی هدرها رو قبل از محتوا میفرستن دلیل نمیشه بگیم که حتما همیشه باید غیر از این باشه. اونا به دلیل ناآگاهی/ناشیگری این کار رو میکنن، ولی کسی هم ممکنه آگاه باشه و به دلیل ساختار برنامش و یا ساده و راحت کردن کدنویسی این کار رو بکنه؛ این کار هیچ مشکلی نداره مگر اینکه دلیل دیگری برای اشکال داشتنش وجود داشته باشه.

اینکه هدرها باید قبل از محتوا ارسال بشن مربوط به ساختار و محدودیت های پروتکل HTTP میشه و ربط خاصی به استایل برنامه نویسی نداره. پروتکل HTTP در یک سطح پایینتر از سطحی که ما داریم توش برنامه نویسی میکنیم قرار داره.

[MMSHFE]

خیلی جاها نمیشه همه دستورات header رو ابتدای برنامه گذاشت. مثلاً ممکنه بخوایم یکسری شرایط رو چک کنیم و برخی دستورات اجرا بشن و بعد از انجام اونها، هدر تغییر کنه. اگه بخوایم همه این کارها رو همون ابتدا انجام بدیم، در برخی موارد لازمه که چندین دستور تکرار بشن. یکی از مزایای بافر خروجی هم همینه که به ما اجازه میده هرجور بخوایم، صفحه رو تغییر بدیم و هدرها رو تنظیم کنیم و وقتی همه چیز آماده شد، اونوقت برای مرورگر بفرستیم. کاربرد دیگه بافر خروجی هم در مواردی هست که میخوایم خروجی قبل از اینکه به مرورگر ارسال بشه، یکسری تغییرات داشته باشه. مثلاً با cURL محتوای یک سایت رو بخونیم و آدرس لینکها رو تغییر بدیم و بعد اطلاعات رو به مرورگر بفرستیم. یا خیلی کاربردهای دیگه. اتفاقاً بافر خروجی یکی از نقاط قوت زبان PHP محسوب میشه که اگه به درستی ازش استفاده بشه، انعطاف پذیری خیلی زیادی در کنترل محتوایی که قراره به مرورگر ارسال بشه ایجاد میکنه.

[Unique]

راستش قرار نیست هر وقت میگیم "کسی هم ممکنه آگاه باشه و به دلیل ساختار برنامش و یا ساده و راحت کردن کدنویسی این کار رو بکنه" یا جملات مشابهی و اینکه "هدرها باید قبل از محتوا ارسال بشن مربوط به ساختار و محدودیت های پروتکل HTTP میشه و ربط خاصی به استایل برنامه نویسی نداره" قانع بشیم که خوب ob_start هر وقتم شد و ما راحت بودیم ok و اگه کسی داره اصولش را رعایت میکنه ناآگاه و ناشیه !

خیر اینطور نیست ،‌ الان مهمترین موضوعی که در برنامه نویسی وب مطرح هست جدا سازی منطق برنامه از خروجی یا همون Presentation هستش ! من برام خیلی جای سوال داره اگه کسی هنوز اسپاگتی کد میزنه و سر این موضوع بحث میکنه که output buffering در کیفیت کدنویسی تاثیر داره یا نه (البته کلی میگم و کسی برداشت به خودش نکنه) خوب حالا اگه کسی منطق برنامش را جدا کرد دیگه موضوعات مربوط به header در presentation اتفاق نمیفته که بخواد نگرانش باشه.

باز هم تاکید میکنم استفاده از output buffering در مورد مشکل headers already sent فقط یک رفع تکلیف هست و اصلا در این مورد نیاز به output buffering نیست ! و شخصا اگه همچین کدی ببینم به کیفیت کدنویسی کسی که نوشته شک میکنم.

[MMSHFE]

درسته. برای مثال، من خودم از Output Buffering بیشتر برای دریافت اطلاعاتی که بصورت Stream داره میاد و جمع کردنش یکجا و بعد از دریافت علامت پایان اطلاعات، انجام تغییرات روی اون و نهایتاً ذخیره توی دیتابیس یا نمایش به صورت دلخواه استفاده میکنم. اتفاقاً اگه بحثهایی مثل UTF-8 without BOM و تنظیمات صحیح PHP و... رعایت شده باشه، بدون Output Buffering هم کد کار میکنه (حتی اگه وسط کد از تابع header استفاده شده باشه). ولی خوب برای کسانی که اسپاگتی کد مینویسن و هنوز به مهارت کافی توی رعایت استانداردها نرسیدن، یک ابزار کمکی اضافه هم محسوب میشه.

[Unique]

راستش یه جورایی احساس کردم اگه کسی این پست را بخونه طرف output buffering نره ! برای یکبار دیگه تذکر میدم که این تکنیک یکی از جالبترین قابلیت ها توی php هست و بعضی جاها به قدری توی performance و حل کردن مشکلاتی تاثیر داره که عدم یادگیری و استفاده درست از اون باعث نقصان در تسلط بر php میشه ! اما در مورد headers already sent که مربوط به session و cookie و header های دیگه میشه فقط برای رفع تکلیف هست و شایسته است که برنامه نویس بدونه داره چیکار میکنه تا اینکه بیاد با یک ob_start مشکلش را پایان بده !

[eshpilen]

خوب ob_start هر وقتم شد و ما راحت بودیم ok
بله بنظر بنده Ok هست، مگر اینکه مشکل واقعی در جای دیگری ایجاد کنه.
حداقل برای صفحات عادی که خروجی اونا حجم زیادی نداره که بافر کردن اونا محتمل باشه مشکل خاصی در جای دیگری ایجاد کنه.


و اگه کسی داره اصولش را رعایت میکنه ناآگاه و ناشیه !
اصول؟
کدام اصول؟
سند و دلیل روشن و محکمی برای این اصولی که میگید دارید؟
بنده تاحالا چیزی در این مورد ندیدم و ذهنم هم نمیرسه.

بحث ارسال هدرهای قبل از محتوا، همونطور که گفتم صرفا به ساختار و محدودیت های پروتکل HTTP مربوط میشه و در سطح برنامه نویسی PHP الزامی نداره.


من برام خیلی جای سوال داره اگه کسی هنوز اسپاگتی کد میزنه و سر این موضوع بحث میکنه که output buffering در کیفیت کدنویسی تاثیر داره یا نه (البته کلی میگم و کسی برداشت به خودش نکنه) خوب حالا اگه کسی منطق برنامش را جدا کرد دیگه موضوعات مربوط به header در presentation اتفاق نمیفته که بخواد نگرانش باشه.
اینا که گفتی همه کلی گویی و مبهم گویی بود.
هیچ دلیل و سند روشن و محکمی بازم دیده نمیشه.
اصلا معلوم نیست دقیقا چی گفتی.
ظاهرا میگی اگر کسی حتی در موارد و جاهای معدودی در کدش هدری رو بعد از محتوا ارسال کرد، اسپاگتی کد میزنه!
میتونی این رو ثابت هم بکنی؟


باز هم تاکید میکنم استفاده از output buffering در مورد مشکل headers already sent فقط یک رفع تکلیف هست و اصلا در این مورد نیاز به output buffering نیست ! و شخصا اگه همچین کدی ببینم به کیفیت کدنویسی کسی که نوشته شک میکنم.
بازم کلی گویی و مبهم گویی.
عزیزم با نظر شخصی و اینطور نظراتی که دقیقا مشخص نیست درست هستن یا نه هیچ چیزی ثابت نمیشه.
بنده هیچ مرجع و قانون ثابت شده ای در این زمینه سراغ ندارم.
شما سراغ داری، اثبات محکمی براش داری، خب بیار!

[Unique]

eshpilen عزیز . دوست خوب من . نمیدونم چرا همیشه دنبال source و مدرک و مقاله و این جور چیزا هستی ! من هر چی بگم باز هم شما یا میگی مبهم گویی یا کلی گویی !
در مورد بحث headers already sent بر مبنای صحبت شما "اینکه هدرها باید قبل از محتوا ارسال بشن مربوط به ساختار و محدودیت های پروتکل HTTP میشه" و من هم قبول دارم ! و شما سندیتش براتون قابل قبوله !
برنامه نویسی که این را میدونه نیاز نیست header هاش را بیاد وسط کار بنویسه ک هبه مشکل ارسال کاراکتر ها بخوره ! خوب این protocol که کلی آدم با سواد و منبع از نظر شما گردآوری کردن و نمیشه بهش گفت محدودیت را ررعایت میکنه و بدون نیاز به output buffering میاد و header ها را قبلش میفرسته !

در مورد اسپاگتی کد هم منظور من اینه اگه شما منطق را از خروجی برنامه جدا کنی(اسپاگتی ننویسی) ، چون در لایه منطق خروجی نداری ! پس header ها بدون نیاز به output buffering ارسال میشوند.
خیلی از مسائلی که توسط من و دیگر دوستان در کمک به بقیه توی این انجمن مطرح میشه از روی تجربه هستش و سواد تئوریک نیست. حالا هر کسی هر جور تمایل داره کار کنه.

[SilverLearn]

به نظر من هم کسی که کمی حرفه ای تر می خواد کار کنه اسپاگتی نمی نویسه کدهاشو که بخواد به header و اطلاعاتی که می خواد وsend کنه اصلا فکر کنه و.....

از یه نظر هم خیلی از دو کاربر eshpilen و uniqe خوشم میاد چون هر کدومشون تا یه تاپیک زده میشه میان و اطلاعاتشون رو به رخ هم میکشن و eshpilen خان همش در پی گرفتن مشکل از uniqe خان هست...........

[eshpilen]

eshpilen عزیز . دوست خوب من . نمیدونم چرا همیشه دنبال source و مدرک و مقاله و این جور چیزا هستی ! من هر چی بگم باز هم شما یا میگی مبهم گویی یا کلی گویی !
چون آدم وقتی سواد و تجربش بالا بره میفهمه که واقعا هیچ چیزی جای اثبات منطقی و دلیل و سند درست و حسابی رو نمیگیره. یک چیزی که بقدر کافی روشن و محکم باشه. البته در خیلی موارد نمیشه به دلایل و اسناد کاملا روشن و محکمی دست پیدا کرد، این کار غیرممکن یا بسیار دشواره و صرف نمیکنه، ولی حداقلش اینه که ادعاهای روی هوا هم نمیکنه یا در همون حدی هم که برای اثبات واقعی تلاش میکنه و چیزهایی در این ارتباط بدست میاره، خودش خیلی مفیده.

همینطوری نیا بگو باید اینطور و نباید اونطور! این که نشد.
یه حرفی میزنی باید دلیلش روشن و محکم باشه و برای مخاطب قابل درک.
نظر و تصورات شخصی به دردی نمیخوره.
حتی اگر تجربه هم داری خب باید کیس و نمونه ارائه کنی حداقل.


خوب این protocol که کلی آدم با سواد و منبع از نظر شما گردآوری کردن و نمیشه بهش گفت محدودیت را ررعایت میکنه و بدون نیاز به output buffering میاد و header ها را قبلش میفرسته !
ببین اصلا معلوم نیست چیزی که میگی دقیقا چی داری میگی!
ولی تاجاییکه فهمیدم بازم پروتکل HTTP رو ربط میدی به برنامه نویسی PHP.
و اینم باز خودش کلی گویی و مبهم گویی و بدون اثباته.
در سطح پایین خیلی محدودیت ها و ساختارها هست که در سطوح بالاتر ما دلیل و نیازی نداریم باهاشون سر و کله بزنیم. زبانهای سطح بالا، کتابخانه ها، فریمورک ها واسه همین بوجود آمدن که برنامه نویس نگران خیلی از این مسائل و محدودیت های سطح پایین نباشه و وقت و انرژی خودش رو صرف حل اهداف نهایی بکنه بجای سر و کله زدن با مسائل فنی.
ضمنا حتی پروتکل HTTP هم لزوما بی نقص و اشتباه نیست. یه چیزی هست سالها پیش طراحی شده و اون موقع اینقدر تجربه و دانش فعلی وجود نداشته. بنابراین لزوما معیار مطلق چیزی نیست، اونم برای پیشرفت ها و شرایط آینده. وحی منزل که نیست! در یک مصاحبه ای از طراح زبان سی++ پرسیده بودن که اگر سی++ رو الان میخواستید از صفر طراحی کنید همینطور طراحیش میکردید؛ ایشون گفته بود این چه سوالیه! معلومه که نه؛ الان تجربهء خیلی بیشتری دارم و میبینم که خیلی اشتباهات رو در طراحی مرتکب شدم یا حداقل میتونستم خیلی بهتر طراحیش کنم. (البته تاحدی به مضمون نقل کردم - متن دقیقش یادم نیست).


در مورد اسپاگتی کد هم منظور من اینه اگه شما منطق را از خروجی برنامه جدا کنی(اسپاگتی ننویسی) ، چون در لایه منطق خروجی نداری ! پس header ها بدون نیاز به output buffering ارسال میشوند.حالا یخورده واضح تر شد.
ولی بهرحال بنظر بنده هیچ حرف کلی و مطلقی رو نمیشه بدون اثبات درخورش زد.
شاید مواردی هم در این قاعده و تجربیات شما نگنجن.
من میگم دلیل خاصی نداره که در این زمینه قانونی وضع کنیم.
در برنامه نویسی سطح بالا آدم محدودیت بیخودی اضافه نمیکنه.
بعدم اسپاگتی کد شما میگی.
چیزی اگر شیء گرا و MVC نبود لزوما اسپاگتی و بدردنخور نیست.
مثالش خود زبان PHP که اینقدر هم موفق و مفید بوده.
راههای و روشهای بدوی تر و محدودتری هم برای اینکه ساختار برنامه رو تاحد زیادی تمیز و مرتب بکنی وجود دارن. حالا در بعضی موارد کافیه و در بعضی موارد هم نه.
شاید خیلی جاها اصلا صرف هم نکنه بخوای اینقدر جنگولک منگولک بازی دربیاری سر شیء گرایی کامل و دقیق و MVC و این حرفا.
در این زمینه ها حتی بین علماش هم اختلاف نظر هست به گمانم!!
یه زبانی مثل پایتون شیء گراییش حتی Public و Private هم نداره به اون صورت و این جزییات رو اونقدر مهم ندونستن.
خیلی از نرم افزارهای مشهور و موفق هنوز هم نه شیء گرایی کامل دارن و نه الگوی طراحی مثل MVC، و بعضیا تازه دارن تغییر ساختار پیدا میکنن. در عین حال اینا بقدر کافی بنظر بنده تاحالا خوب و تمیز و موفق بودن و کدهای اونا ارزش داره، ولو شیء گرایی آنچنانی نداشته باشه ولو MVC نباشه. زحمت کشیدن و کدشون هم خوب و بقدر کافی کاراست و از کار خیلی برنامه نویسهای دیگر هم خیلی بهتره.
شیء گرایی و الگوی طراحی همیشه و در همه مورد لزوما همه چیز یا مهمترین چیزها نیستن.
برنامهء خود بنده هم بقول شما اسپاگتیه، ولی تا حالا ندیدم نمونهء سیستم رجیستر و لاگینی رو که از نظر امکانات و انعطاف و امنیت و کمال و استحکام الگوریتم ها در اون حد باشه. اگر بهترین نباشه حداقل برجسته است. ضمنا بعدا اگر نیاز شد و فرصت داشتم فکر نمیکنم شیء گرا و MVC کردنش کار خیلی سختی باشه.

بهرحال هدف و ارزش نهایی یه برنامه اینه که کار مورد نظر رو به خوبی انجام بده. صرفنظر از اینکه کد داخلش از چه روشهای ساختاری استفاده کرده.
من نمیگم شیء گرایی و MVC مهم یا حتی لازم نیست، ولی میگم که همینطور نزنید توی سر هر برنامه و برنامه نویسی که اینا رو رعایت نکرده. اون برنامه نویس ممکنه در کل از شما توانمندتر باشه و برنامش هم بهتر.

[Unique]

خوب این protocol که کلی آدم با سواد و منبع از نظر شما گردآوری کردن و نمیشه بهش گفت محدودیت را رعایت میکنه و بدون نیاز به output buffering میاد و header ها را قبلش میفرسته !

ببین اصلا معلوم نیست چیزی که میگی دقیقا چی داری میگی!

منظورم اینه که وقتی میدونیم این protocol چنین محدودیتی داره ما هم جوری کد مینویسیم که این protocol انتظار داره ، نه اینکه بیایم برای حل مشکلمون از تکنییکی که اصل موجودیتش برای حل این مشکل نیست استفاده کنیم‌!

راستش من چون زیاد به مباحث آکادمیک و تئوریک و اثبات و سند و دلیل و برهان و روشن و محکم و اینجور چیزا اهمیت نمیدم و معیار هام کلا باهات فرق داره هر چی هم که بحث کنیم فایده نداره ! اصلا نمیتونم نصف پست شما بنویسم که حالا بیام شرح بدم ! ما تسلیم. از این به بعد هر جایی خواستم میگم تجربه شخصی خودمه و اگه جایی هم یادم رفت دوستان به قرینه معنوی از ما قبول کنند.

[Unique]

از یه نظر هم خیلی از دو کاربر eshpilen و uniqe خوشم میاد چون هر کدومشون تا یه تاپیک زده میشه میان و اطلاعاتشون رو به رخ هم میکشن
خیلی لطف دارین که از بنده حقیر خوشتون میاد اما من یادم نمیاد با eshpilen جایی بحث کرده باشم حتی اینجا هم این کار نکردم و بحث را جمع کردم. دیدگاه ما دو نفر اصلا شبیه به هم نیست و هیچوقت به یک مقصد نمیرسیم و من این را درک میکنم اما برای عقیده همه ارزش قائلم و احترم میگذارم.

موضوع دیگه اینکه خدایی نکرده من قصد به رخ کشیدن هیچ چیزی را ندارم و قصدم فقط ارائه تجربیاتم برای دوستانی هست که سوالاتی دارند. هیچوقت هم چون چیزی را جایی خوندم توصیه نمیکنم مگه اینکه عملی استفاده کرده باشم و در غیر این صورت حتمی اشاره میکنم که شخصا تست نکردم !

[SilverLearn]

شرمنده بنده هم قصد جسارت نداشتم .....
این هم مسلم هست که شما فقط برای کمک به دوستان اینجا هستید و من به نمایندگی از همه از شما به خاطر حضورتون تشکر می کنم

و در آخر هم دوباره اگر جسارتی کردم معذرت می خوام .......

[eshpilen]

هیچوقت هم چون چیزی را جایی خوندم توصیه نمیکنم مگه اینکه عملی استفاده کرده باشم و در غیر این صورت حتمی اشاره میکنم که شخصا تست نکردم !
بعضی چیزا تستی نیست.
یا ماهیتش طوریه که نیازی به تست نداره و یا اصلا نمیشه تست کرد.
مثلا در امنیت و رمزنگاری تست بعضی چیزها یا غیرممکنه یا اونقدر دشوار و زمانبر و هزینه بر که شاید صرف نکنه، ولی اینا رو از نظر تئوریک میشه کاملا درک کرد و بقدر کافی روشن و محکم هستند.
یجورایی شبیه ریاضیات.