doc.designMode + afbeeldingen

[Sgrovert]

Ik ben momenteel bezig aan een eigen wysiwyg editor en heb de basis ver af. Tot nog toe heb ik alle functionaliteit die ik wilde hebben kunnen vinden op het internet. Echter ben ik nu tegen een probleem aangelopen wat ik niet kan vinden.

Om te beginnen zal ik een kleine uitleg geven, bij het uploaden van een afbeelding word deze door de server geresized, en een verwijzing naar de bestanden in de database opgenomen. Op het moment dat er een webpagina opgehaald word waarin een afbeelding zit, word de locatie van de afbeelding opgehaald en vertaald naar een standaard link.
Om een webpagina te bewerken ben ik een editor aan het bouwen. Deze maakt gebruik van de functionaliteiten van doc.designMode (ik weet de officiele naam even niet, maar hoop dat dit duidelijk is).

Nu wil ik naast de wysiwyg mode ook de mogelijkheid hebben om de html rechtstreeks te bewerken. Momenteel heb ik devolgende (relevante) code

code:

<scipt>
doc.designMode = "on";

function wysiwygmode() {
doc.body.innerHTML = "value"
}
function htmlmode() {
doc.body.textContent = "value"
}
</script>

Hierin is "value" de content van de betreffende pagina, welke uit de database gehaald word, en door javascript nabewerkt word om correct weergegeven to worden.

Even een voorbeeld :
In de database staat

code:

<p>alinea 1</p>
[afbeelding_1]
<p>alinea 2</p>

In html-mode is er geen probleem, en komt precies deze tekst op het scherm te staan. In wysiwyg mode moet er echter wel vertaald worden. Daar wil ik immers de afbeelding laten zien. Momenteer word bovenstaande code als volgt vertaald :

code:

<p>alinea 1</p>
<--[afbeelding_1]--><IMG alt="" src="http://etc."><--[afbeelding_1]end-->
<p>alinea 2</p>

Voor het weergeven is dit prima, de afbeelding word netjes in de wysiwyg mode getoont, en ik bewaar de orginele code (=[afbeelding_1]) zonder dat deze in wysiwyg mode getoont word. <-- --> is immers html-commentaar.
Als de pagina bewerkt is en weer in de database opgeslagen moet worden is terugvertalen erg makkelijk, ik zoek mijn begin en eindtag van de afbeelding op <--[afbeelding]--> ... <--[afbeelding]end--> gooi dat hele stuk weg en vervang het door [afbeelding].

Tot zover gaat alles goed. Nu komt het probleem waar ik tegenaanloop,
Op het moment dat er met de afbeelding gesleept word in het wysiwyg venster, splits deze het commentaat van de begin en eind-tag. In code doet hij

code:

<p>alinea 1</p>
<--[afbeelding_1]--><--[afbeelding_1]end-->
<p>alinea 2</p>
<IMG alt="" src="http://etc.">
<p>alinea 3</p>

Vraag 1: Hoe zorg ik ervoor dat hij bij verslepen de begin en eind-tag meeneemt?
Of weet iemand een slimmere manier om de orginele tag te bewaren. Achteraf de gegenereerde html terugvertalen naar interne codes is geen optie. De tag bevat namelijk ook info of de afbeelding ergens naar toe moet linken etc.

Vraag 2: Ik wil dat als er met de de rechtermuisknop op de afbeelding geklikt word een menu getoont word, waarmee ik instellingen aan de betreffende afbeelding kan doen. Waar kan ik ergens een goed voorbeeld vinden van hoe dit moet?
Binnen mijn editor zouden afbeeldingen dan met de linkerknop verplaatst kunnen worden, en met de rechtermuisknop gepositioneerd (links / mindden / rechts)

[R4gnax]

Sgrovert schreef op donderdag 04 maart 2010 @ 19:26:

Vraag 1: Hoe zorg ik ervoor dat hij bij verslepen de begin en eind-tag meeneemt?
Of weet iemand een slimmere manier om de orginele tag te bewaren. Achteraf de gegenereerde html terugvertalen naar interne codes is geen optie. De tag bevat namelijk ook info of de afbeelding ergens naar toe moet linken etc.

Gebruik een custom protocol i.p.v. http:// (dus iets als cms:// , wysi:// , etc.) en verander dat onder de kap naar een normale http:// link enkel en alleen voor weergave in 'design view'? Daarmee draai je het hele verhaal om en zorg je dat in 'code view' er enkel één img tag staat met een duidelijk herkenbaar patroon (nl. jouw custom protocol), terwijl in 'design view' er achter de schermen meer tags (kunnen) bestaan.

Wil je die vertaalslag ook niet maken en in beide views met enkel een img tag werken, kijken dan eens naar HTML5 data-* attributen.

[ Voor 7% gewijzigd door R4gnax op 05-03-2010 08:42 ]

[bindsa]

JavaScript:

<scipt>
doc.designMode = "on";

function wysiwygmode() {
doc.body.innerHTML = "value"
}
function htmlmode() {
doc.body.textContent = "value"
}
</script>

Dit gaat niet werken, je moet <script> doen i.p.v. <scipt>.

[tonyisgaaf]

L0calh0st schreef op zaterdag 06 maart 2010 @ 19:45:
[...]


Dit gaat niet werken, je moet <script> doen i.p.v. <scipt>.

offtopic:
Tenzij je natuurlijk wil dat het ge-scipt wordt. Toch denk ik dat de TS gezien het feit dat er al het een en ander lijkt te werken normaliter <script> schrijft. Maar da's natuurlijk puur intuïtie.

[Sgrovert]

R4gnax schreef op vrijdag 05 maart 2010 @ 08:41:
[...]
Gebruik een custom protocol i.p.v. http:// (dus iets als cms:// , wysi:// , etc.) en verander dat onder de kap naar een normale http:// link enkel en alleen voor weergave in 'design view'? Daarmee draai je het hele verhaal om en zorg je dat in 'code view' er enkel één img tag staat met een duidelijk herkenbaar patroon (nl. jouw custom protocol), terwijl in 'design view' er achter de schermen meer tags (kunnen) bestaan.

Dat is eigenlijk wat ik al doe. In code view staat mijn eigen code met idd een custom protocol. Het probleem doet zich in de design view voor.
Ik moet op een of andere manier bijhouden waar een afbeelding naartoe verplaatst word. Ik dacht dit op te lossen door een tag toe te voegen (<-- tag -->) en te kijken waar deze heen geplaatst is. In code ziet het er als volgt uit

code:

tekst tekst etc.
<--tag--><img /><--tag-->
tekst tekst etc.

Na verslepen van de afbeelding is het img gedeelte netjes verplaatst, maar zijn de tags niet meegenomen. De code ziet er dan als volgt uit :

code:

<img />
tekst tekst etc.
<--tag--><--tag-->
tekst tekst etc.

De tags zijn dus niet naar de nieuwe plek meeverhuist.

Als een afbeelding alleen een afbeelding zou zijn, zou het opzich makkelijk weer terug te coderen zijn. Echter coderen de tags voor veel meer dan de afbeelding alleen. Ze zorgen voor de plaatsing (links/rechts), afmetingen, javascript die bij de afbeelding hoort en maken van de afbeelding desgewenst een link.

Dit gaat niet werken, je moet <script> doen i.p.v. <scipt>.

Was het maar zo simpel

[Sgrovert]

Vandaag heb ik eindelijk de oplossing voor het probleem gevonden. Het is een meerstappen plan geworden, maar voor de geinteresseerde zal ik proberen uit te leggen hoe ik het uiteindelijk gedaan heb.
Als idee ben ik ervanuit gegaan dat een iframe door de wysiwyg editor als een vast object gezien word. Dit betekend dat als je het iframe verplaatst je frame op een andere plek te staan komt, en de afbeelding die er in getoond word ook meegaat.
Om het uiteindelijk voor elkaar te krijgenis er eerst gezorgd dat het iframe dezelfde afmetingen als de afbeelding heeft en op dezelfde plek in de pagina weergegeven word. Hiervoor is een "xml" file gemaakt welke de data van de afbeelding als volgt codeert :

code:

url=http://afbeelding1.html|align=left|width=150|height=112

Deze gegevens kan Javascript ophalen, en hiermee wordkan het iframe als volgt gebouwd worden :

code:

<iframe name="[image_1]" src=http://afbeelding1.jpg align=left width=150 height=112 id="image"
frameborder=0 marginheight=0 marginwidth=0 scrolling=no>
Warning, your browser is to old to display images</iframe>

Deze code laat de afbeelding netjes zien, en door het iframe in de wysiwyg mode te verplaatsen neem je alle code mee. Daarbij is deze ook eenvoudig terug te coderen. De <iframe en </iframe> tags kunnen makkelijk gevonden worden. En als er name="[image_ in te vinden is weet je zeker dat er in het iframe bedoeld is om een afbeelding te huisvesten.

Enige probleem is dat het FFmomenteel nog niet werkt om het iFrame te verslepen. Morgen even kijken wat het precieze probleem is.

Allemaal bedankt voor de hulp en het meedenken

[ Voor 12% gewijzigd door Sgrovert op 14-05-2010 03:39 ]