Nyomtató üzenetek a felhasználó webes alkalmazások

Nyomtató üzeneteket a felhasználó - a meglehetősen gyakori művelet elvégzésére webes alkalmazás. Ez előfordulhat a feldolgozási formák, lehet, hogy a hibaüzenetek és üzenetek azt mondják, hogy szükség van a regisztrációhoz, amikor a felhasználó megpróbál hozzáférni egy korlátozott része a helyszínen, és sok más esetben.

Nagyon gyakran a teremtés és kimenő üzenetek végzett különböző HTTP-kéréseket. Általános szabály, hogy kényelmes a használata átirányítás feldolgozása után formák (a problémák elkerülése érdekében a gombokkal Back és Refresh), de ugyanakkor egy természetes ideje létrehozni az üzenet - ez a feldolgozás ideje alatt formák és intézkedik kapcsolódik hozzá. Miért? Képzeljük el, mi az üzenet kellene kinéznie: „Az egységek száma megrendelt»egérpad«sikeresen megváltozott 7-12”. Miután az átirányítást, esetleg egy teljesen más szempontból a funkcionalitás az oldalt, akkor egy extra fejfájás - meghatározni, hogy mi volt azelőtt.

Leggyakrabban, üzenetek jelennek éppen a POST-kérést, amely részt vesz a feldolgozás formája - ez nem helyes, a felirat: „ez a lap elavult,” elrontani élet (ha a felhasználó tetszik, hogy próbálja meg a Vissza gombot).

Valaki használja az átirányítás, intett a kezével, hogy a baráti üzenet.

Ugyanakkor van egy egyszerű és kézenfekvő módja, hogy az élet jobb. Annak ellenére, hogy a bizonyítékok, valamilyen oknál fogva nem kellett látni, hogy valaki használta - legalábbis amikor néztem baj forrása.

Tehát, van egy kis probléma - az üzenet legyen „élő” a különböző lekérdezések. Mi kell egy szöveges üzenet halad mechanizmust arra az oldalra, hogy kell megjeleníteni. Ön valószínűleg már gondoltak az ülésen.

Igen, általában akkor igazad van. Más módszerek, mint például egy globális változó, nem teszik lehetővé, hogy az adatokat az esetben, ha az átirányítás (Megjegyzés Maxim Naumenko). Plusz én is szoktam, hogy minden egyes képernyőn az alkalmazás lehetősége volt, más információval együtt, az üzenetek megjelenítéséhez hogy alakultak az előző képernyőkön. Ez kényelmes, mert nem kell, hogy készítsen külön képernyőkön üzenetek megjelenítéséhez, és a felhasználónak nem kell kattintani az egérrel egyszer. De az igazság, itt figyelembe kell venni a tervező -, hogy válassza ki a területet, ahol az üzenetek jelentek meg.

Az ötlet nagyon egyszerű, és ez lehet megvalósítani a segítségével egy pár osztályok.

Az első dolog, ami eszébe jut -, hogy hozzon létre egy osztályt üzenet. amelyek, sőt, ez egy üzenet volt a mi egyszerű osztály diagram. Az üzenet képesnek kell lennie arra, hogy megvédjék magukat az ülésen, valamint a kijelző is.

Ahhoz, hogy a munkamenet változót használjuk a $ _SESSION.

Megjegyezzük, hogy a $ _SESSION - egy tömb, mi csak az egyik eleme a tömb index „session_message”.

Ebben az esetben meg kell kezelni a „tömb tömbök” - az a tény, hogy tárolja az elem „session_message”. egy tömb, ez az üzeneteket továbbítani kell (ők persze, lehet, hogy több).

Ha nem találja a fonalat, itt az ideje, hogy ecsettel fel a kézi szentelt részeket ülések és tömbök.

Megjegyzendő, hogy ezen a ponton a munkamenet fel nem maga a tárgy, de csak a szöveget az üzenet. OOP lehetővé teszi számunkra, hogy tovább változtatni a viselkedését a módszer send (). klienskij megváltoztatása nélkül a kód arra utal, hogy ez a módszer (például a jövőben a munkamenet lehet rögzíteni teljesen kifogást Message. Ha lesz egy csomó mezők).

Képzeljük el, mi mi volna a segítségével funkciókat. Talán működne message_send ($ txt). még mindig azt message_to_page funkció ($ txt). Most kell adni a lehetőséget a különböző viselkedés különböző típusú üzeneteket. Függvény hívások változik: message_send ($ txt, $ fajta). message_to_page ($ txt, $ fajta). Mi lesz, hogy fésülje át a teljes alkalmazás kódját a keresést az ilyen funkciók, korrekciók.

Ezt el lehet kerülni előre várva a helyzet bemutatásával egy üzenetet egy asszociatív tömböt: $ msg [ „txt”]. $ Msg [ 'kedves']. mivel egy olyan függvényhívás csak egy lehetőség. Úgy érzi, mivel arra törekszik, hogy legyen egy osztályban?

Tehát, OOP lehetővé teszi, így nem gondolni mindent előre.

Menj előre. Az egyes oldalakon, van, hogy az összes beérkezett üzenetek és távolítsa el őket a munkamenet után. Ez nagyon hasonlít az olvasó leveleket a postafiókból.

A következő osztály - Beérkezett - csak erre a célra, és célja.

Próbáljuk meg üzenetküldő rendszer.

Hozzunk létre egy nagyon egyszerű példa, ami válaszul az űrlap elküldését jelenti a másodpercek számát a percet.

Minden munka tömbök és ülések már rejtve osztályok és a végső kódot néz ki, szép és egyszerű.

Hozzon létre egy könyvtárat a web szerver, majd hozza létre, a három fájlt, és próbálja meg a forgatókönyvet, hogy működik. Megjegyzés problémák vissza, és frissítse a gombok nincsenek ott.

Most képzeljük el, hogy létrehoz egy bonyolult portál, ahol, mint általában, az oldalakon van néhány háztömbnyire, és mindegyik tartalmazhat magában egy külön alkalmazás.

Itt találkozunk két nehézséget:

Szeretném látni az üzenetek listája jelenik meg egy bizonyos része az oldal, és már felvette egy jó hely ez.
A probléma az, hogy szükség van a parancs futtatásához $ inbox-> toPage () abban a pillanatban, ami megfelel a helyzet az üzenetek listája az oldalon. Ha meg akarjuk változtatni a pozícióját a listán, akkor kell menni a kódot, de nem jó ez az állandó változás a portál keretben. A legjobb megoldás az lenne, hogy kössön üzenetek külön modul, amely egyetlen ismert, csak azt kell csatlakoztatni a kerethez.
Amely mentes a run-ins szigorú sorrendben. Sőt, ha az eredmény a visszavonása Inbox nem függ a rendszer működését (ebben a lépésben - az összes adat már van egy ülés), ezért az extra komplexitás?
Ahhoz, hogy a megjelenés (tervezési) az üzenet listában nem kell aggódnia, a HTML-kódot, amit úgy varrják módszerek toPage () Bejövő üzenetek és osztályok. Általános szabály, hogy meg kell változtatni a PHP-kódot annak érdekében, hogy módosítsa a design.

Hogy megpróbálják megoldani az első probléma, akkor hozzon létre egy puffer, amely tárolja a munka eredményeit kimenő levelek.

Talán lesz néhány hasonlóan (Inbox) dolgokat, és meg kell, hogy hozzon létre egy puffer rendszert. Annak érdekében, hogy a félreértések elkerülése végett, ha akinek következtetésre kell jutnunk, hogy az elnevezés a puffert. Mi lesz tárolni valahol szekvencia, amely szerint meg kell kimeneti puffer - lehetőleg egy külső fájlt, könnyebb változtatni.

Már ez a kísérlet megoldásokat ad nekünk az ötletet, hogy az XML, mint egy olyan tároló közbenső adatokat. És használata XSLT foglalkozik majd a második probléma.

Nem tér ki a tényt, hogy az XML és XSLT mi. Ha nem ismeri ezeket a dolgokat, zvon.org jó kiindulópont.

Az ötlet az, hogy létrehoz HTML-kód nem úgy, ahogy toPage (), és az XML-struktúrát. oldalas dokumentum jön létre formájában tanga XML-kód (ez szolgál majd a „puffer”), és fel fogjuk használni a XSL-transzformáció az utolsó fázisban a forgatókönyvet.

Kezdeni, képzeljük el, hogy kell eredményeként a fő része a kódot.

Mi ez - egészen egyszerűen kitalálni - két oszlop alakú. Jegyezzük meg, PHP-script kell készítenie csak tanga - ez nagyon egyszerű. Továbbá az, hogy a fő tag nem fontos - tudunk elején például ez lesz kényelmes a programozó. Hogyan valósítható meg. Lehetőség van, szinte változtatás nélkül semmit, használd a kimenet pufferelés helyett HTML-kódot az XML, és a végén csak meg a kimenetet egy húr. De aztán elvesztik rugalmasságukat - például néha szeretnénk kiírni hibakeresési információkat közvetlenül az oldalon (a visszhang). Ugyanakkor, a PHP fejlesztők dolgoznak DOM-modul, mely egy fejlettebb módja, hogy hozzon létre és küldjön egy dokumentumot fa. Ha azt akarjuk, hogy hajtsák végre a DOM, akkor, hogy dolgozza át az összes alkalmazást, változó kimeneti húrok létrehozását DOM-elemekkel. Úgyhogy inkább tárolni az XML-alapú ábrázolását tárgyak a tárgyak maguk, egymás gyűjtő közös XML-dokumentumot. Ez nem olyan nehéz, akkor csak kismértékű módosításával. Meg fogja találni, hogy egy ilyen eszköz nem kapcsolódik szorosan egy adott módszer tárolására XML-adatokat, és meg fog tenni az átmenetet a DOM segítségével „egy kis vér.” Először is, fontos, hogy minden létesítmény van toPage () metódust. Ez a hasonlóság tesz minket gondolkodni, hogyan kell vezetni egy új, közös szülő osztályban. Legyen minden osztály, amely képes létrehozni darab XML-dokumentum oldal fog örökölt egy osztály, hogy vigyázni fog az XML-ábrázolás az objektumot. Nevezzük Outputable.

toPage () metódus készül üres - ebben az esetben van szükség, mivel jelzi, hogy milyen kell külső „matryoshka” osztályú kommunikálni a belső osztály. Azonban lehetne hívni az alapértelmezett végrehajtását, ha azt látjuk, hogy sokan vannak tárgyak, amelyek ugyanazt a következtetést magam ezen az oldalon.

Bejövő üzenetek és néhány osztályok változott - most mindketten örökölt Outputable. valamint a változás és módszerek toPage ()

I megváltoztatta a kimenetre - most, ahelyett, hogy a közvetlen kimenet oldal külső képviselete ideig tartják a Outputable. amely „ül” az egyes tárgyakat. appendOutput () módszer egy helyettesítő echo () szerkezet. Felvenni a kimeneti objektum getOutput () módszerrel.

Most lássuk, mi a kliens oldali kódot, amely megoldja ugyanazt a problémát, mint korábban.

A legfőbb újdonság - az objektum $ global_content. akinek a neve önmagáért beszél. Ebben az esetben tartozik az osztály Outputable. Valós alkalmazásokban akkor valószínűleg létrehoz egy külön osztályt az oldal tartalmát.

Ha jobban megnézed, a jelentős része a script nem sokat változott - ugyanaz a postaládájába. azonos toPage (). Hozzáadott nyilatkozat arról, hogy a csomag tartalma a közlemény lista jelenik meg az oldal tartalmát. A változás már létrehozott két üzenetet.

Ha látni az eredményt, már csak azt kell készíteni a XSL-sablont.

Mi van még?

Először is, ez biztos, hogy a komplex projektek -, hogy valódi függetlenségének modulokat. Az, hogy a stack eredmények oldal most ellenőrzi külső XSL-sablont, és nem függ a sorrendben run-ins.

Bármilyen modul generál XML-adatokat egy munkájuk eredményeként, fel lehet használni a projektben. Mellesleg, ez az egyik előnye templát-motorok, amelyekben a létrehozását adatok szekvencia hivatkozni módszerek (hozzárendelni, stb) egy adott motorhoz, amelyben nincs közös szabvány.

A másik előnye - a könnyű hibakeresés. Ha fut a script, akkor veszi észre, hogy minden oldalon van debug következtetés - XML-prototípusa, amely nagy egyszerűsíti hibakeresés alkalmazások.

Mi azt is meg kell gondolni -, hogyan lehet létrehozni tárgyak üzeneteket. Ez nem mindig kényelmes a használata az új kódot közvetlenül a kliens. De talán ez a téma egy másik cikk.

Végül, vágtató a kilátások: