Изходни съобщения до потребителя в уеб приложения

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

Много често, създаването и на изхода на съобщенията се извършва на различни HTTP-заявки. Като правило, това е удобно да се използва пренасочване след обработка форми (за да се избегнат проблеми с бутоните се и опреснете), но в същото време естествен път да създаде посланието - това е времето на форми за обработка и предприемане на действия, свързани с него. Защо? Представете си какво си съобщение трябва да изглежда по следния начин: "Броят на дяловете нареди" Подложка за мишка "успешно е била променена от 7 до 12". След пренасочването, вероятно по съвсем различен по отношение на функционалността на страницата, тя ще бъде допълнително главоболие - да се определи какво е било направено преди това.

Най-често се показват съобщения точно в пост-молба, която се занимава с обработка на форми - това не е правилно, надпис "тази страница е остаряла", развалят живота (когато потребителят пожелае да се опита бутона Назад).

Някой използва пренасочване махна с ръка към приятелски съобщението.

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

Така че, имаме проблем - посланието трябва да бъде "на живо" в различните заявки. Имаме нужда от текстово съобщение, минаваща механизъм за страницата, която се нуждае, за да го покажете. Вие вероятно вече сте, че на сесията.

Да, като цяло, а след това, че си прав. Други методи, като например чрез глобална променлива, не позволяват данните да се пазят в случаите, когато пренасочване (Забележка Максим Naumenko). Плюс това аз също обикновено се прави така, че всеки екран в заявлението е имал възможност, заедно с друга информация, за да се покаже на съобщения, които са се образували в предишните екрани. Това е удобно, тъй като тя не трябва да се подготвят отделни екрани, за да показва съобщения, и потребителят не трябва да кликнете с мишката веднъж. Но, истината, тук е необходимо да се помисли за проектанта - за да изберете областта, в която са се появили съобщения.

Идеята е много проста, и това може да се реализира с помощта на чифт класове.

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

За достъп до променлива сесия се използва $ _SESSION.

Имайте предвид, че $ _SESSION - е масив, ние използваме само един от елементите на масива с индекс "session_message".

В този случай ние трябва да се справят с "масив от масиви" - на факта, че ние съхраняваме в "session_message" на елемента. е масив, това е списъкът на съобщенията да бъдат предадени (те, разбира се, може да има няколко).

Ако не можете да намерите на нишката, че е време да реша на ръчните раздели, посветени на сесии и масиви.

Имайте предвид, че в този момент в сесията постави не самия обект, но само текста на съобщението. Обектно-ориентиран ни позволява по-нататъшно се промени поведението на изпращане на метод (). klienskij без промяна на кода, който се отнася до този метод (например, в бъдеще в сесията може да се запише напълно възрази Съобщение. Ако ще има много полета).

Представете си какво би направил с помощта на функции. Може би ние ще функционира message_send ($ TXT). все пак ще message_to_page функция ($ TXT). Сега ние трябва да се добави възможността различно поведение при различни видове съобщения. Извиквания на функции се променят: message_send ($ TXT, $ натура). message_to_page ($ TXT, $ натура). Ще трябва да прерови целия код приложение в търсенето на такива функции, които правят корекции.

Това може да се избегне по-рано в очакване на ситуацията чрез представяне на съобщение като асоциативен масив: $ съобщ [ 'TXT']. $ Съобщ [ "вид"]. докато при извикване на функция е само една опция. Вие се чувствате като се стреми да се превърне в клас?

Така че, обектно-ориентиран ви позволява да си позволи да не мисля за всичко предварително.

Продължавай. На всяка страница, ние трябва да се въвеждат всички получените съобщения и да ги премахнете от сесията след това. Това е много подобен на четенето на писма от пощенската кутия.

На следващия клас - Inbox - само за тази цел и е предназначено.

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

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

Цялата работа с масиви и сесии сме скрити в класове и окончателния код изглежда добре и просто.

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

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

Тук се сблъскваме с две трудности:

Бих искал да видите списък на съобщения се появяват в определена част на страницата, а вие вече сте хващали добро място за това.
Проблемът е, че това е необходимо, за да изпълните команда $ inbox-> toPage () в момента, което ще съответства на позицията на списък от съобщения на страницата. Ако искаме да променим позицията на списъка, ще трябва да отидете в кода, но това не е добре за тази постоянна промяна на рамката на портал. Най-доброто решение би било да се заключи, съобщения в отделен модул, който е известен само само, че тя трябва да бъде свързан към рамката.
Това е свободен от сблъсъци строга последователност. Наистина, след като в резултат на оттеглянето на Inbox не зависи от работата на системата (в този етап - всички данни, които вече имаме в една сесия), защо допълнително сложността?
За да се поддържа външния вид (дизайн) на списъка със съобщения да се притеснявате за HTML-код, който сме пришита методи toPage () съобщение Входящи и класове. Като правило, е необходимо да се променят PHP-код, за да променят дизайна.

За да се опита да реши първият проблем, можете да създадете буфер, в който да се съхраняват резултатите от работата на изхода Inbox.

Може би ще имаме някои подобни (от входящата поща) неща, и че е необходимо да се създаде система буфер. За да се избегне объркване, където чието заключение трябва да се стигне до именуването на буфери. Ние ще се съхраняват някъде последователност, според която трябва да бъде изход буфер - за предпочитане във външен файл, да го направи по-лесно да се правят промени.

Още този опит за решения ни дава идеята за използване на XML като средство за съхраняване на междинните данни. И използването на XSLT стилове ще се занимава с втория проблем.

Няма да се спирам на факта, че XML е, и това, което е XSLT. Ако не сте запознати с тези неща, zvon.org е добра отправна точка за разглеждане.

Идеята е да се генерира HTML-код не е в начина, по който toPage (), както и структурата на XML. страниците на документ ще бъде създаден под формата на ремък с XML-код (тя ще служи като "буфер") и ще използваме XSL-трансформация в последния етап от сценария.

За да започнете, нека си представим, че трябва да е в резултат на основната част от кода.

Какво е това - просто предполагам - две мнения и форма. Имайте предвид, PHP-скрипт трябва да се подготвят само слип - това е много проста. Освен това, от порядъка на главния маркер не е важно - могат да бъдат поставени в началото, например, ще бъде удобно да се програмист. Как да го приложат. Възможно е, почти без да се променя нищо, използване буфериране на изхода, вместо HTML код за показване на XML, и в крайна сметка, само за да заснемане на продукцията в низ. Но тогава губим гъвкавост - например, понякога искам да изходна информация за отстраняване на грешки директно на страницата (при използване на ехо). В същото време, PHP разработчиците работят върху DOM-модул, който предлага по-напреднал начин за създаване и изпращане на дърво документ. Ако искаме да приложи DOM, че ще трябва да преначертае всички приложението, промяна на изходните конците в създаването на DOM-елементи. Така че аз предпочитам да съхранявате XML-базирани представяне на обекти в самите предмети, последователно събиране на обща XML-документ. Това не е толкова трудно, трябва само лека модификация. Ще откриете, че този механизъм не е прикрепен здраво към специфичен метод за съхранение на XML данни, а това ще направи прехода към DOM използване на "малко кръв." На първо място, ние се отбележи, че всеки един от нашите съоръжения са метод toPage (). Това сходство трябва да ни накара да мисля за това как да се въведе нов общ родител клас. Нека всеки клас, който е в състояние да създаде парчета страница XML-документ ще бъде наследена от клас, който ще се грижи за XML-представяне на обекта. Наречете го Outputable.

toPage () метод се прави празен - в този случай това е необходимо, като показател за това как трябва да външен "матрьошка" клас да комуникират с вътрешния клас. Въпреки това, има може да бъде поканен да стандартното внедряване, ако забележим, че има много обекти, които същите заключения Себе си на тази страница.

Съобщението Inbox и някои класове се променили - сега и двамата са наследени от Outputable. както и промяна и методи toPage ()

Промених начина, по който да се изход - сега, а не на пряк изход към страница на външното представителство за момента се пази в Outputable. който "седи" във всеки един от обектите. appendOutput () метод е заместител ехо () структура. За да изберете най-изход обект, се използва getOutput () метод.

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

Основната новост - в обект $ global_content на. чието име говори за себе си. В този случай, той принадлежи към класа на Outputable. в реални приложения, най-вероятно ще се създаде отделен клас за съдържанието на страницата.

Ако се вгледате внимателно, съществената част от сценария не се е променила много - една и съща пощенска кутия. същото toPage (). Добавен изявление, че съдържанието на списъка със съобщения показва в съдържанието на страницата на. За промяна сега генерира две съобщения.

За да видите резултата, остава само да се подготви XSL-шаблон.

Какво имаме?

На първо място, че е безопасно да се вземат по-сложни проекти - за осигуряване на реална независимост на модули. Редът на подреждане на страницата с резултати от сега се управлява от външен XSL-шаблон, и не зависи от реда на сблъсъка.

Всеки модул, който генерира XML-данни в резултат на тяхната работа, може да се използва в проекта. Между другото, това е една от предимства пред шаблон двигатели, при които създаването на последователност от данни е да се позове методи (присвоява и т.н.) на даден двигател в които няма общ стандарт.

Друго предимство - лесното отстраняване на грешки. Ако стартирате скрипта, ще забележите, че на всяка страница има за отстраняване на грешки-заключение - XML-прототип на този велик опростява отстраняване на грешки в приложения.

Какво сме ние също трябва да се мисли за - как да създавате обекти съобщения. Тя не винаги е удобно да използват новия код директно в клиента. Но може би това е тема за друга статия.

И накрая, галопиращ за перспективите: