ugrás a tartalomhoz

Archívum - Aug 17, 2007 - Fórum téma

nem a tényleges ablakméretet adja vissza a offsetWidth/Height

szabozee · 2007. Aug. 17. (P), 18.02
Az alábbi script -elvileg- lementi az aktuális window méretet, majd beállítja 800x600-ra. Mikor megnyomom a vissza gombot a böngészőben, akkor meg visszaállítja az eredeti ablakméretet. DE NEM! Mégpedig azért, mert a document.documentElement.offsetWidth és Height párja sem azt a méretet adja visza(IE és FF nél sem), mint amekkora a window, hanem egy kicsivel kevesebbet, így mindig egy kicsit kisebb lesz az ablak, míg el nem fogy. Bár semmi jelentősége nincs, hogy onload-ban van-e, vagy sem, de onloadban is ugyanazt adja vissza. Rengeteg alternatíva van, ahogy meg lehet oldani ugyanezt a feladatot. Nem alternatív megoldást keresek, hanem az a kérdés, hogy így miért nem jó, mi a hiba ebben a kódban ?

window.onunload = unloadPage;
Width=document.documentElement.offsetWidth;
Height=document.documentElement.offsetHeight;
function unloadPage(){ window.resizeTo(Width,Height); }
window.resizeTo(800,600);
 ■

Regex illeszkedés túl mohó

inf · 2007. Aug. 17. (P), 17.23
Sziasztok

Regexel akadtam el egy template vezérlő készítése közben.
A lényeg, hogy a template objectemnek megadok egy mintát, amit elsőre feldarabol a vezérlők elhelyezkedése szerint, majd végigmegy a tömbön, és kiszedi a vezérlőket, helyükre pedig vagy .*ot vagy a vezérlő belsejében megadott regex kódot illeszti

kb így néz ki az egész:
var a=new Template("ez egy szám: </szam:[\\d]+/>")
ebből csinál olyat, hogy
["ez egy szám: ","</szam:[\\d]+>"]
na most ezt nyilván itt egy global flages regexel szedem szét
utána végigmegyek egy nem global flagessel, és azzal kapom szét a vezérlőt, vagy ha nem vezérlő, akkor escapelem, hogy ne zavarjon be majd regex gyártásnál.

a vezérlőből csinálok egy olyat, hogy
["szam","[\\d]+"]
majd hozzáírom a készülő regex forrásához a második részt, szóval a regex forrása, ami a minta alapján készült így néz ki:
"ez egy szám: ([\\d]+)"
szóval a "szam" hoz tartozó regexet beraktam egy capturing groupba, és ha ráillesztem ezek után egy stringre, akkor a backreference[1]ből tudom majd kinyerni.

tehát a végeredmény mondjuk ennél a stringnél:
"ez egy szám: 24"
"24" lesz a backreference[1]en, amit majd egy objectben adok vissza így:
{szam:"24"}
a problémám ezzel az egésszel annyi, hogy ha a vezérlőben megadott regex kódban is van capturing group, és nem csak egy vezérlő van, akkor eltolódik a backreference sorrendje, és más adatok fognak bekerülni a végén az objectbe, ami nem túl jó.. szóval szűrni szeretném a capturing groupos regexel rendelkező vezérlőket, vagy ha nem megy, akkor replaceelem a ( eket (?: ra

a másik gondom, hogy a vezérlőket kinyerő regex mohó, tehát ha ilyet írok, hogy
"</vmi/>/>/>"

CDATA manipulálás JavaScripttel

Wabbitseason · 2007. Aug. 17. (P), 11.56
Létezik egy olyan nyomdászati fogalom, hogy "árvasor/fattyúsor". Ha egy oldal tetejére az előző oldalon kezdődő bekezdésből csak egyetlen sor lóg át, vagy ha egy oldal alján induló többsoros bekezdés számára csak egy sor marad és a többi sor átcsúszna a következő oldal tetejére, az ilyen magányos sorokat esztétikai okból el szokták tüntetni.

Megrendelő megalkotta e fogalom webes változatát, melynek lényege, hogy többsoros szövegnél az utolsó sorban legalább két szónak kell lennie.

Ez könnyen megoldható úgy, hogy a mondatok utolsó két szava közötti szóközt nbsp-re cseréljük. Ilyen "mondatvégi" szópárnak minősül természetesen egy CDATA utolsó két szava, hiszen nincs rá garancia, hogy írásjellel végződik a szöveg.

Technikai okból ezt nekem most JavaScripttel kell megoldanom.

Hogy ne kelljen túl bonyolult reguláris kifejezést írni (hogy például HTML forrás attributúmainak tartalmához ne piszkáljak hozzá), arra gondoltam, szép lenne, ha a JavaScript függvény a DOM-nak csak a CDATA részével dolgozna.

Van valami gyors és elegáns megoldás a CDATÁ-k kigyűjtésére? Nem szeretnék végigmenni az összes node-on és egyesével vizsgálgatni, mert érzésem szerint az túl lassú volna.
 ■