Szerkesztett tartalom darabolása
Aki fejlesztett már tartalomkezelőt, talán belefutott abba a problémába, hogy hogyan lehetne megoldani a tartalomhoz tartozó bevezető szöveg és a több oldal tárolását. A következőben erre próbálunk ötletet adni.
A megoldáshoz egyetlen mezőt használunk, ez fogja tartalmazni a teljes dokumentumot: bevezetőt és a többi oldalt. Annyi a dolgunk, hogy szerkesztéskor jelölni kell - hogy tudjuk mi is és az alkalmazás is-, hogy melyik szakasz hol kezdődik és meddig tart. A következő képpen alkalmazzuk:
Láthatjuk, két színű elválasztót használunk:
- piros: bevezető szöveg határolója
- kék: új oldal (oldaltörés)
Ezeket a következőképpen kapjuk:
- piros: <hr class=”morebreak” />
- kék: <hr class=”pagebreak” />
Tehát a szövegbe be kell szúrni a hr-t - a színeket korábban már definiáltuk css-ből-. A beszúrást elvégezhetjük manuálisan, kereshetünk plugint a szövegszerkesztőhöz, vagy magunk írunk egy plugint, mint ahogy azt mi tettük( a képen a “–Format–” mellett lévő két ikon a saját plugin a funkcióhoz). Majd szerkesztés befejeztével még az adatbázisba való mentés előtt célszerű egy cserét végezni:
- <hr class=”morebreak” /> => [--more--]
- <hr class=”pagebreak” /> => [--page--]
(Ismételt szerkesztés esetén nyilván a cserét visszafelé kell elvégezni…)
A weben való megjelenítéshez külön tudjuk venni a bevezető szöveget, és a tartalmi részt a következő lekérdezéssel:
select if (instr(mezo,'[--more--]')=0,'',substr(mezo,1,instr(mezo,'[--more--]')-1)) bevezeto, if (instr(mezo,'[--more--]')=0,mezo,substr(mezo,instr(mezo,'[--more--]')+10)) tartalom from table1
- bevezeto: ha van [--more--] , add vissza az előtte lévő rész, különben semmit
- tartalom: ha van [--more--], add vissza az utána lévő részt, különben az egész mezőt
Így megkapjuk a “bevezeto” mezőben a bevezető szöveget, a “tartalom” részben pedig a többi szöveget az összes oldalával együtt. Az oldalakra bontást egy explode ( [--page--] mentén) parancs végezheti, fanatikusabbak egy reguláris kifejezést is illeszthetnek a szövegre. (Utóbbi megoldás vélhetően lassabb.) A kapott tömbből a megfelelő elemet visszaadva megvan a kért oldal.
Az eljárás előnyei:
- egyszerű adattárolás, nincs szükség plusz “felesleges” mezőkre
- ebből következik elég egy wysiwyg editor, ami jelentősen növeli az alkalmazás sebességét
- szerkesztés közben átlátható marad a tartalom
- tartalomban való keresés egyszerűbb, mivel egy mező van (ez nem igaz, mert html-ben nehéz keresni sql-ben…)
Hátrányai:
- megjelenítéskor sok oldalas dokumentumok esetén sok adatot kell fetch-elni “feleslegesen”
- html tagpárok könnyen szétvághatók (special thanks to sztahanov
)


[...] http://www.dev2.hu/2007/10/15/szerkesztett-tartalom-darabolasa/ « előző | Zoltan — 2007. 10. 15. 20:19 [...]
Pazar. A hátrány meg nálam csak akkor hátrány, amikor épp nem a cachebül veszi ki
Ennek a módszernek az a legnagyobb - mondhatni végzetes - hibája, hogy ketté tud vágni tagpárokat. Tehát pl. csinál a júzered egy három bekezdéses idézetet (blockquote), és vidáman be fogja rakni a törést az idézet első bekezdése után.
ez inkább a juzer végzetes hibája. ezt is meg kell tanulni használni. mikor jönnek olyannal, hogy a wordből bekopizott szöveg miért esik szét? akkor most mit csinálsz? megmutatod, hogy hogy kell használni. erre ez a megfejtés szerintem.
Ha csak 3 júzered van, akkor meg tudod nekik mutatni, de sokezernél nem számíthatsz arra, hogy tisztában lesznek a HTML alapjaival - hiszen pont azért van a vizivig editor, hogy ne kelljen ezt tudniuk
igen, tudom, már agyalok a powerjuzer verzión.
Én maradok a jól bevált 2 mezőnél
Pubi júzerek forevör
megíram a tinymce plugint, most csekkolom. pazar lesz. és free letölthető. illetve egy búzasöré.
WYSIWYG editor után amúgy sem árt betenni egy a HTML-t rendberakó kódot, és mivel a HR elem block típusú, ezért nem helyezhető például egy BLOCKQUOTE-on, vagy P-n belülre. Lehet, hogy a WYSIWYG editor beteszi, de a kód rendberakása után ennek rendeződnie kell.
Ja, egyébként vágni az első bekezdés után kell automatikusan, oldalakra tördelni pedig bűn. Az oldalakra tördelés üzleti szempontok miatt (bannerek, a cikk végigolvasottságának mérése) lett bevezetve, és nagyon nem felhasználóbarát. És admin felületen is kényelmesebb, ha nem kell ilyennel szórakoznia az újságírónak és a webprogramozónak.
Nem tudsz tökéletes HTML-pucolást csinálni, júzerek pl. sokszor (főleg kopizott szövegben) egy justifyoló divet pakolnak az egész posztjuk köré, na azt oldjad meg okosan, nem lehet. (De ha ezt meg is oldod, kitalálnak mást, nem tudsz lépést tartani.)
A megoldás a több külön mező.
kis türelmet. mingyá kész a plugin. süt, főz, nem tossza szét a domot. nemsoká belinkelem, lehet tesztelni.
Szerintem is két beviteli mező:
http://kepfeltoltes.hu/071016/skycms_www.kepfeltoltes.hu_.jpg
A lapozást pedig csinálja meg a PHP, de készítettem már JS-el működő lapozást is egy cikkhez.
http://www.dev2.hu/attachments/szoveg/pagebreak.zip
na, ennyi futotta, ennél jobban nem tudom megoldani. Akárki akármit mond, a szövegszerkesztést meg kell tanulni. “@sztahanov: egy justifyoló divet pakolnak az egész posztjuk köré, na azt oldjad meg okosan, nem lehet.” ez a varacskolás.
Olyan ez, mint mikor a kedves titkárnő, legyen Julika, írja a word docot, és címsor jön beírja, megáll, kijelöli a szöveget, 20px-re veszi a méretét, pl jobbra igazítja, aláhúzza, kiszínezi, és tol még két entert alá a hely miatt. Írja tovább. Többi címnél eljátsza ugyanezt. Majd rájön, hogy nem néz ez ki jól nyomtatva, mert balra kéne igazítani, az aláhúzást levenni, meg a színe se jó. Ekkor Julika fogja a dokumentumban található címeket, legyen pl 15-20, egyenként megformázza a szükséges formátumra, eltolva vele kb 20 percet, mert nem mindig sikerül elsőre eltalálni a betűméretet, meg a színt. Holott ha Julika definiált volna egy címsor stílust, akkor címenként egy kattintással beállítja a cím stílusát, és később a stílus módosításával tudja a dokumentum összes címét átírni.
A papír sok mindent eltűr. Nem látszik hogy készült. Egy blogbegyzésben, mikor Pistike írja a tegnap estét, megintcsak nem számít(nem annyira…)
Ha viszont egy híroldal, vagy bármi olyan oldal, aminek számít, hogy hogy néz ki a szerkesztett lap (legfőkébb seo miatt ugye, tiszta legyen a kód, jól nézzen ki, egyformák legyenek a bekezdések stb.), akkor nincs mese, oda úgymond szöveget szerkeszteni tudó embert kell ültetni, aki tudja használni a jól átgondolt, kitalált stíluslapokat (tinyben a ‘content_css’), nem pedig a “bold”-ra kattint, ha vastag betű kell.
Miután ezzel elébbé kimagyaráztam a szükséges tudást
, úgy vélem a fenti plugin használható lesz. Talán elég jól sikerült megoldani azt, hogy ne vágjuk szét a tagpárokat, de ugye 100%os védelem nyilván nincs, enélkül is lehet igen böszme szöveget szerkeszteni, akár egybe van a bezető, akár nincs. Szerintem.
Naszóval, teszteljétek (akinek van ideje), és írjátok meg az esetleges bugokat, talán! kijavítom.
[...] teszteljétek legyetek szívesek. bajokat ide: http://www.dev2.hu/2007/10/15/szerkesztett-tartalom-darabolasa/ « előző | Zoltan — 2007. 10. 16. [...]
Ok, én nyilván a blog.hu-n posztoló sokezer titkárnőre gondolok egy ilyen problémánál. Merőben kényelmesebb 10 szkilled júzernek csinálni egy ilyen cuccot
De hajrá.
hát nyilván. azért nem kell annyi funkció a titkárnőnek, mert nem tudja használni. de ha rendesen akarsz szerkeszteni, meg kell tanulni. ezért is írtam…
text/plain rulz