@darkterminal тъй кат гледам си поредния комплексар на който половия орган расте когато се впусне да помага на някого...

е расте ли чурката... мехмед?

@darkterminal тъй кат гледам си поредния комплексар на който половия орган расте когато се впусне да помага на някого...

е расте ли чурката... мехмед?

 

Благословен бъди и нека добротата да изобилства в твоя живот.

Не съм специалист по PHP но задачата ми изглежда изпълнима. Има поне два начина да се направи:

 

1. След кликане на бутона да се препрати съдържанието към PHP скрипта и той да си свърши работата като в response потока се обърне това което трябва като PDF и се върне на браузъра който вече трябва да се погрижи да го интерпретира както трябва - ако потребителя има Acrobat Reader или подобен ще се отвори с него, ако няма ще се даде възможност за Save на файла. Недостатък на този начин е че ще се загуби съдържанието на страницата или най-малкото тя ще се рефрешне защото дефакто се изпраща заявка към сървъра и се извиква директно PHP код.

 

Съдържанието може да се въстанови, то идва в PHP файла така или иначе. Това става с вмъкването на половин ред PHP код. Остава рефрешването на същата страница, което обикновенно не е проблем. Ако страницата не е голяма и външните файлове към нея са вече кеширани, няма и да се усети обновяването й.

 

Начини, колкото щеш!

Не съм специалист по PHP но задачата ми изглежда изпълнима. Има поне два начина да се направи:

 

2. Ако идеята е страницата да остане както си е а само при клик на бутон да се експортне съдържанието на дадено поле от форма в PDF то това може да стане с AJAX(пасивно извикване на страница) по следния начин:

 

<script type="text/javascript" src="jquery.min.js"></script>   // изтеглете актуалната библиотека

<script type="text/javascript">

function executeTextAreaToPDF() {

textAreaField = document.getElementById("content");

$.get("exportToPDFServlet?content=" + escape(textAreaField.value));    // Предполагам кода за PHP трябва да е аналогичен - $.get("somephp.php?content=" + escape(textAreaField.value));

return false;

}

</script>

....

....

<a href="#" onclick="executeTextAreaToPDF();">Do PDF</a>

 

Не забравяй да кръстиш полето TextArea - "content" защото с това име то се изчита от PHP скрипта. (<textarea name="content" id="content"....)

 

 

Съдържанието на PHP(somephp.php) файла трябва да стане само така:

<?php

        $content = $_GET['content'];

        include_once( 'dompdf/dompdf_config.inc.php' );

        $dompdf = new DOMPDF();

        $dompdf->load_html($content);

        $dompdf->render();

        $dompdf->stream('Example.pdf');

   

?>

 

ПП: Не съм специалист по PHP така че не мога да гарантирам за правилното изписване на синтаксиса и командите.

ПП2: Лека корекция на скрипта, сори но синтаксиса ми куца.

 

Същият ефект може да се постигне с един ред в PHP кода:

header("Content-Disposition: attachment; filename=\"" . basename($filename) . "\"");

 

Страницата не се променя и идва само PDF файла и то задължително пита какво да направи с него, а не го отваря в прозореца на браузъра. Трябва да се създаде временен файл, обаче.

Същият ефект може да се постигне с един ред в PHP кода:

header("Content-Disposition: attachment; filename=\"" . basename($filename) . "\"");

 

Страницата не се променя и идва само PDF файла и то задължително пита какво да направи с него, а не го отваря в прозореца на браузъра. Трябва да се създаде временен файл, обаче.

 

Мисля че идеята е да не се създава изобщо файл, това е най-удачното решение. От една страна не се товари сървъра да записва и чете файлове които в даден момент може да заемат доста място ако не се чистят, след това трябва да се следи дави са с уникални имена и т.н. за да не се върне нещо което реално не трябва. За това е по-удачно и това което мисля че прави php скрипта с този ред - $dompdf->stream('Example.pdf'); - връща генерираното съдържание като Stream поток и указва на браузъра какъв тип файл му се връща в случая Example.pdf за да знае клиента как да го интерпретира. Ако има Acrobat Reader или плъгин в браузъра ще се отвори директно там, ако ли не ще се даде възможност за Open/Save на файла.

 

Колкото до кеширането и рефреша на страницата, изобщо не мисля че рефреш на страницата и изпращането към сървъра на информацията и последващото и възстановяване е удачен вариант, дори бих казал ужасен. Идеята на тези редактори е да са на клиента и да работят на ниво браузър, а не да се прави заявка от бутоните към сървъра за щяло и нещяло. Ако тръгнем по този път защо например не си решим проблема с бутон като <B> bold и вместо да го правим с JavaScrip не го направим на сървъра и понеже е кеширано той да ни върне съдържанието на страницата но с bold-нат шрифт. Незнам дали някой изобщо ще се съгласи на такова решение.

 

Както казах РНР не ми е силна страна като език, ориентирам се само по командите и евентуално по това което предполагам че правят, Ако нещо от синтаксиса на езика ми куца си го признавам програмирам на друг език и там нещата са "уж" аналогични но не съвсем.

Мисля че идеята е да не се създава изобщо файл, това е най-удачното решение. От една страна не се товари сървъра да записва и чете файлове които в даден момент може да заемат доста място ако не се чистят, след това трябва да се следи дави са с уникални имена и т.н. за да не се върне нещо което реално не трябва. За това е по-удачно и това което мисля че прави php скрипта с този ред - $dompdf->stream('Example.pdf'); - връща генерираното съдържание като Stream поток и указва на браузъра какъв тип файл му се връща в случая Example.pdf за да знае клиента как да го интерпретира. Ако има Acrobat Reader или плъгин в браузъра ще се отвори директно там, ако ли не ще се даде възможност за Open/Save на файла.

 

Колкото до кеширането и рефреша на страницата, изобщо не мисля че рефреш на страницата и изпращането към сървъра на информацията и последващото и възстановяване е удачен вариант, дори бих казал ужасен. Идеята на тези редактори е да са на клиента и да работят на ниво браузър, а не да се прави заявка от бутоните към сървъра за щяло и нещяло. Ако тръгнем по този път защо например не си решим проблема с бутон като <B> bold и вместо да го правим с JavaScrip не го направим на сървъра и понеже е кеширано той да ни върне съдържанието на страницата но с bold-нат шрифт. Незнам дали някой изобщо ще се съгласи на такова решение.

 

Както казах РНР не ми е силна страна като език, ориентирам се само по командите и евентуално по това което предполагам че правят, Ако нещо от синтаксиса на езика ми куца си го признавам програмирам на друг език и там нещата са "уж" аналогични но не съвсем.

 

Съгласен съм, че колкото е по-удобно дадено нещо толкова по-добре. Подобни неща обаче са се правили и преди появата на Ajax и други подобни технологии.

 

А това генерирано съдържание Example.pdf нали е пак файл на диска. Не съм проверявал, но ако е както казваш и PDF файла се отвори в браузъра (при наличие на плугин) старата страница ще се смени, което е неудобно. За мен това би било неприемливо. Ако се използва реда  header("Content-Disposition: attachment; filename=\"" . basename($filename) . "\"") винаги браузъра ще пита какво да направи със файла и страницата ще остане видима.

 

При кратко търсене попаднах на Javascript библиотеки за генериране на PDF файлове, което позволява търсеното преобразуване да стане изцяло в браузъра на клиента, без да се праща до сървър. PHP не е необходим, нито сървър. Това мисля е още по-удобно решение в този случай. Има и особености, разбира се.

 

 

Незнам дали някой изобщо ще се съгласи на такова решение.

 

Всеки, който знае само едно решение ще се съгласи на него, каквото и да е то, понеже няма избор. {:->)

 

А това генерирано съдържание Example.pdf нали е пак файл на диска. Не съм проверявал, но ако е както казваш и PDF файла се отвори в браузъра (при наличие на плугин) старата страница ще се смени, което е неудобно. За мен това би било неприемливо. Ако се използва реда  header("Content-Disposition: attachment; filename=\"" . basename($filename) . "\"") винаги браузъра ще пита какво да направи със файла и страницата ще остане видима.

 

Не, не е файл на диска, генерира се в паметта на сървъра след което тръгва поток (това е смисъла на Stream-а) от пакети  който хвърчат към клиента. Когато всички пакети се получат като резултат от изпълнената заявка браузъра има за цел да ги интерпретира както може. Ако има програма която отваря pdf файлове като Acrobat Reader то по подразбиране файла директно ще се отвори с нея. Ако има плъгин в браузъра за pdf файлове също на Adobe пак ще се отвори директно в браузъра но не в нов прозорец а като popup, който няма да бъде блокиран от браузъра просто защото е изпълнен в резултат на заявка (клик) а не от таймер на страницата например. Ако случайно няма софтуер който да интерпретира потока от данни то тогава файла ще бъде сглобен като Example.pdf и ще се появи Open/Save диалогов прозорец.

Преди Ajax единствения начин да бъде направено подобно нещо е IFrame и дори тогава пак има прехвърляне на данни между фреймовете с javascrip. В последствие javascript библиотеките напреднаха и сега има възможност за пасивно извикване на страници без реално да се прави заявка към сървъра от основната страница. Естесвено има си и ограничения но това което ОР искаше е напълно реализуемо като функционалност.

Не, не е файл на диска, генерира се в паметта на сървъра след което тръгва поток (това е смисъла на Stream-а) от пакети  който хвърчат към клиента. Когато всички пакети се получат като резултат от изпълнената заявка браузъра има за цел да ги интерпретира както може. Ако има програма която отваря pdf файлове като Acrobat Reader то по подразбиране файла директно ще се отвори с нея. Ако има плъгин в браузъра за pdf файлове също на Adobe пак ще се отвори директно в браузъра но не в нов прозорец а като popup, който няма да бъде блокиран от браузъра просто защото е изпълнен в резултат на заявка (клик) а не от таймер на страницата например. Ако случайно няма софтуер който да интерпретира потока от данни то тогава файла ще бъде сглобен като Example.pdf и ще се появи Open/Save диалогов прозорец.

Преди Ajax единствения начин да бъде направено подобно нещо е IFrame и дори тогава пак има прехвърляне на данни между фреймовете с javascrip. В последствие javascript библиотеките напреднаха и сега има възможност за пасивно извикване на страници без реално да се прави заявка към сървъра от основната страница. Естесвено има си и ограничения но това което ОР искаше е напълно реализуемо като функционалност.

 

Не бях сигурен за файла.

 

Та, значи има доста начини.

 

Въпрос:

А какво би станало, ако клиента не приема по някаква причина потока от PDF файла и междувременно изпрати още една такава заявка?

Редактирано 10 август 201510 г. от supervas (преглед на промените)

Не бях сигурен за файла.

 

Та, значи има доста начини.

 

Въпрос:

А какво би станало, ако клиента не приема по някаква причина потока от PDF файла и междувременно изпрати още една такава заявка?

 

Ами какво ще се получи ако кликнеш на даден бутон и след това си затвориш браузъра, това е същото. Има браузър има резултат, няма браузър няма да се получи нищо. Не може хем да разрешаваш интернета до даден сайт хем и след това той да не ти връща резултат защото нещо е "забранено". Потока от PDF файла не се разпознава като pdf файл докато не се сглоби от клиента, както страницата след обработка от сървъра се връща под формата на пакети, браузъра я сглобява, ако има грешки в пакетите си ги извиква отново от сървъра и като види че са всички без грешки ги сглобява и ги дава под формата на страница на потребителя. В случая с PDF файла е същото, само че вече е оказано че това е файл от тип pdf в stream-а и браузъра го интерпретира по посочения по-горе начин.

Ако клиента изпрати повече от една заявка е редно програмиста да реши как да реагира, ако времето между двете заявки е много кратко (някой е кликнал няколко пъти или дабълклик на бутона) може да се игнорират такива заявки и да се изпълни само първия път. Тук има свобода - дали бутона да стане неактивен за кратко за да се избегне дабъл клик (с javascript) или на сървъра да се напише такава логика която да помисли и за такъв проблем защото наистина генерирането на файлове не е лек процес, особено пък pdf-и, някой може да реши да пренатовари сървъра с измислени заявки и да стане проблем. Доста неща за които трябва да се помисли, не е само да се върне файла на клиента.

Преди Ajax единствения начин да бъде направено подобно нещо е IFrame и дори тогава пак има прехвърляне на данни между фреймовете с javascrip.

 

Освен IFRAME, можеше да се ползва и FRAME елемента.