[CMS] Over het invoegen van tabellen in een CMS-editor

[gvanh]

Hallo!

vandaag weer wat bezig met het uitbreiden van de editor van mijn CMS. Nadat ik gisteren de mogelijkheid heb ingebouwd om een textbox (lees: DIV) toe te voegen aan de HTML, wil ik vandaag de mogelijkheid maken om ook een Tabel in te voegen.

Nu is het vrij makkelijk om de gebruiker te vragen hoeveel rijen en kolommen hij wil en vervolgens de html daarvoor in de editor te rammen, maar het lijkt me, dat dat mooier kan. Bovendien zou ik graag de mogelijkheid inbouwen om later de eigenschappen van de tabel middels een pop-up weer te wijzigen. Bovendien lijkt het me mooi om de gebruiker de mogelijkheid te bieden zelf in te stellen wat de breedte van iedere kolom/rij mag zijn.

Nu vroeg ik mij af wat anderen hier zoal voor oplossingen voor hebben gevonden.

Alvast dank voor de reactie!

[gorgi_19]

Zie P&W FAQ - HTML / javascript /css, etc...

>> Webdesign & Graphics

[Zoefff]

Kijk eens naar http://www.dynarch.com/htmlarea/ , en dan voornamelijk naar http://www.dynarch.com/htmlarea/examples/fully-loaded.html , volgens mij is dat precies wat je zoekt namelijk.

Wellicht kan je aan de hand daarvan wat ideen opdoen

[Michali]

Ik heb dit zelfs opgelost door via het DOM model de tabel elementen te benaderen en zo de eigenschappen aan te passen. Wat wil je precies weten dan?

En wat had je zelf in gedachten bij een mooiere oplossing voor het aantal rijen en kolommen?

[gvanh]

@Zoefff:
Holy shit! Da's inderdaad wel een hele soepele editor. En hij werkt zelfs in Mozilla! Wat een mooie lul die dat heeft gemaakt!

Ik ga 'ns even hard geinspireerd raken hier!

Dank voor de tip!

[Zoefff]

You're welcome

Er is nog zo'n editor, precies hetzelfde systeem, en werkt ook uitstekend in mozilla. Had ook nog wat leuke trucjes met tabellen dacht ik, maar ik kan hem even niet vinden.

Als ik thuis ben zal ik m ff uit mn bookmarks opvissen

[gvanh]

Ik ben er echt een beetje stil van. Net even rustig een kop koffie gedronken om dit te laten bezinken. Zelf ben ik al best een eind met m'n CMS, maar dit is toch ook wel erg geil.

Voor een voorbeeldje van waar ik nu sta met m'n CMS:
http://cms.thirdwave.nl/admin

Maar goed, die werkt dus alleen in Internet Explorer (>5.5 geloof ik)

[ Voor 14% gewijzigd door gvanh op 07-09-2004 11:23 ]

[Verwijderd]

Ik vind htmlArea echt toch wel een van de minste editors hoor Boordevol fouten, traag, onoverzichtelijke configuratie, etc. Dat het werkt met Midas alla, maar dat is echt peanuts om in te bouwen.

Zodra de editor in een nesting komt die display:block is laadt de editor niet of niet goed, je kan buttons vanuit de toolbar in je document slepen, i18 foutmeldingen, permission denied meldingen, en als je de pagina verlaat terwijl de editor nog niet is ingeladen krijg je ook diverse foutmeldingen omdat ook hier weer is niet de benodigde checks zitten.

[ Voor 70% gewijzigd door Verwijderd op 07-09-2004 11:33 ]

[Zoefff]

Nou, dat ziet er anders ook aardig geil uit

Vergeet niet dat wat jij hebt een complete CMS is he, en HTMLArea is alleen maar een WYSIWYG editor, meer niet. Ik vind ook dat je niet té veel functionaliteit aan zoiets moet toevoegen. Tekst bold/italic/underline maken is leuk, en tabellen zijn ook zeker handig, maar de rest van de opmaak zou ik via CSS laten gaan, en niet via de editor.

Anyway, jou editor ziet er ook prima uit, succes met de rest

[gvanh]

Dank je wel!

Het is wel zo dat dit slechts een editor is, maar dan wel een erg stoere! Bovendien is het kunnen toevoegen/wijzigen van tabellen is toch ook wel erg handy... je moet wat te wensen overhouden he ... wellicht komende dagen toch nog maar 'ns even aan gaan zitten.

[Tjark]

Verwijderd schreef op 07 september 2004 @ 11:29:
Ik vind htmlArea echt toch wel een van de minste editors hoor Boordevol fouten, traag, onoverzichtelijke configuratie, etc. Dat het werkt met Midas alla, maar dat is echt peanuts om in te bouwen.

Gebruik jij een beter/ander alternatief?

[Zoefff]

Er zijn wellicht ook betere alternatieven hoor, dat geloof ik ook wel.

Deze kwam ik ook nog tegen, in ontwikkeling door een mede gotter http://www.jorgenhorstink.nl/development/ , en zo zijn dr nog een paar.

Het is maar wat je wensen precies zijn

[gvanh]

Die is inderdaad ook wel erg soepel. Voelt ook wat solider aan ... op een of andere manier...

[Verwijderd]

TjarkVerhoeven schreef op 07 september 2004 @ 11:36:
[...]

Gebruik jij een beter/ander alternatief?

Ik gebruik momenteel soEditor van siteObjects maar ook deze heeft bugs. Ik ben al wel bezig met een eigen editor, want ik werd een beetje ziek van continue gekloot met editors die maar half werken en ook nog is slecht geschreven zijn.

[gvanh]

@Gordijnstok:
Wellicht een idee om krachten te bundelen?

[Zoefff]

En het resultaat hier te publiceren?

[gvanh]

Haha ... is toch JavaScript ... je hoeft maar de js-jes te downloaden

[HawVer]

Ja.. Maar dan bezigt u de code illegaal. Stel Gordijnstok komt het later weer tegen. Dan baalt hij daar vast van. Maar die html area is wel erg mooi!

[Mithrandir]

HTMLarea loopt hier heel hard vast anders? (IE6, SP2)

Ik denk dat veel van die WYSIWYG editors nog steeds te dicht bij de HTML staan. Ook zijn de invoervelden vaak te klein om er fijn mee te werken.

Wat ik op mijn school zie, is dat er vaak ook misbruik wordt gemaakt van die uitgebreide editors. Leraren die totaal geen gevoel voor stijl hebben, en vinden dat roze tekst op een blauwe achtergrond best leuk is.

Is het niet makkelijker om een minder groot aantal knoppen te maken, een minder groot aantal mogelijkheden, maar wél goed nadenken over wat je doelgroep is en wat die met je editor moeten kunnen. Dat heeft ook nog eens het voordeel dat ze het sneller snappen.

[Verwijderd]

HawVer schreef op 07 september 2004 @ 13:30:
Ja.. Maar dan bezigt u de code illegaal. Stel Gordijnstok komt het later weer tegen. Dan baalt hij daar vast van. Maar die html area is wel erg mooi!

Mijn treeview kan men ook gewoon gebruiken, heb ik ook geen problemen mee

[Verwijderd]

Ik ben zelf al heel wat tijd kwijt aan html editors. Ik gebruik nu htmlArea als basis en schrijf daar omheen mijn eigen dingen. Qua basis is htmlarea erg goed, maar het is gewoon nog niet af! Het scripten kost ook nog eens enorm veel tijd. Wat ik nu heb gedaan is alleen de basisfunctionaliteiten gepakt deze getest, wat extra dingen ingebouwd (word import b.v.) eigen img beheer en nog wat dingen. Dit werkt nu redelijk stabiel. Maar het blijft behelpen. Als ik weer meer tijd ervoor wil en kan nemen dan ga ik verder met htmlArea. Ik denk dat er momenteel geen beter alternatief is.

Wat ik ook heb gedaan om de performance te verbeteren is van htmlarea een popup te maken. Deze popup aanroepen, met de gewenste functionaliteiten. De code via javascript overhalen zodat het allemaal client-side gebeurt. Geen gekloot meer met layout waardoor de editor niet goed opbouwt.

Wat betreft een voorgaande reactie ben ik het helemaal eens dat je alle stijl-elementen eruit haalt. Laat css al het werk doen. Wat ik wel heb gedaan is een css selectiedropdown. hightlight en speciale typen. Je kan met htmlarea makkelijk je eigen css bestanden inladen.

[djluc]

Ik ben op dit moment ook een RTE aan het ontwikkelen. Dit is allemaal redelijk simpel, zeker als je netjes object gebaseerd werkt. Voor tabellen ga ik het systeempje namaken van MS Word. Dus een button waaronder na een klik een selectiesysteempje komt om de tabelgrootte te selecteren. Dat is imo het meest eenvoudige. Ik moet alleen nog iets bedenken voor de borders e.d.

[gvanh]

Verwijderd schreef op 07 september 2004 @ 14:20:
Wat ik nu heb gedaan is alleen de basisfunctionaliteiten gepakt deze getest, wat extra dingen ingebouwd (word import b.v.) eigen img beheer en nog wat dingen. .

Ja, die Word import, dat heb ik al eerder ergens gezien. Hoe werkt zoiets? Is er een standaard JavaScript functie die de ellendige overhead van Word-clipboarddata vervangt door nette HTML, of worden dat soort functies met het handje geschreven (kan ik me niet voorstellen).

[Verwijderd]

gvanh schreef op 07 september 2004 @ 16:16:
[...]


Ja, die Word import, dat heb ik al eerder ergens gezien. Hoe werkt zoiets? Is er een standaard JavaScript functie die de ellendige overhead van Word-clipboarddata vervangt door nette HTML, of worden dat soort functies met het handje geschreven (kan ik me niet voorstellen).

Regular expressions kunnen een hele boel
idee erachter, haal alle stijl eruit, haal alle niet gewenste tags eruit, haal alle dubbele tags eruit, haal alle xml troep eruit en zo kan je nog wel wat verzinnen. bijna geen merkbare vertraging levert het op. headers, Tabellen, basis opmaak en lists worden overgenomen. Daar gaat het toch vooral om.

[Zoefff]

Mithrandir schreef op 07 september 2004 @ 13:49:
Wat ik op mijn school zie, is dat er vaak ook misbruik wordt gemaakt van die uitgebreide editors. Leraren die totaal geen gevoel voor stijl hebben, en vinden dat roze tekst op een blauwe achtergrond best leuk is.

Ik heb mijn htmlarea ook flink aangepast wat knoppen betreft.

Aan de opmaak kan je bijna niets veranderen. Bold/italic/underline/sub/sup kan wel, maar verder zit het allemaal in mn stylesheet. Gebruikers kunnen aangeven of het een titel is, of een kop moet zijn, en dan word dat verder door mn stylesheet afgehandeld.

Geen gekloot met achtergrondkleurtjes en dat soort humbuk dus, vrij basic

[jwchess]

Ik ben zelf wel tevreden over FCKeditor.
Demo hier.

Werkt sinds kort ook onder Mozilla/Firefox.

[Zoefff]

Ah ja, dat was ook de andere editor die ik bedoelde. Heeft alleen geen ondersteuning voor plaatjes. Iets wat ik niet aan users meegeef, maar zelf soms wel wil kunnen gebruiken. Verder idd ook prima editor

[jwchess]

Hij ondersteund wel plaatjes, maar volgens mij hebben ze dat in de demo uitgeschakeld.

Zie de specs:

Image insertion, with upload and server browsing support (version 1.x)

Edit: Ik zie dat alleen versie 1.x plaatjes ondersteund, de nieuwe versie ws. dus nog niet....

[ Voor 22% gewijzigd door jwchess op 07-09-2004 18:30 ]

[djluc]

jwchess schreef op 07 september 2004 @ 18:29:Edit: Ik zie dat alleen versie 1.x plaatjes ondersteund, de nieuwe versie ws. dus nog niet....

Klopt, het is ook nog maar een beta versie.

Ik vind overigens het systeem voor tabellen niet zo geweldig hoor. Waarom niet gewoon ala word snel een tabelletje maken?

[Verwijderd]

Die fckeditor werkt dus nu ook onder mozilla, kijk dan begint het erop te lijken. Tables is inderdaad niet veel. Hij is wel consistenter dan htmlarea op het eerste gezicht. Ik was eerst met deze bezig maar door het gebrek van mozilla ondersteuning ben ik overgestapt.

Toch blijft het behelpen met deze dingen. "Echt" werken doen ze nooit helemaal.

[djluc]

Ik snap niet waarom ze niet met wat meer mensen er aan werken. Er zijn toch ook duidelijk te verdelen onderdelen dus dat moet wel te doen zijn. Dit met betrekking tot FCK editor en andere editors.

[ Voor 16% gewijzigd door djluc op 10-09-2004 15:56 ]

[Verwijderd]

Ik denk dat veel cms'en ze ook weer niet te pas en te onpas gebruiken. Met wat slimme formulieren kan je dezelfde resultaten krijgen. Maar dan weet men zeker dat het goed is. Met een html-editor blijft het afhangen van de persoon die invoert. En ook voor de invoerder is het soms makkelijk om via een bepaalde structuur te werken.

[Priet]

Waarom worden er niet meer Java Applets als editor gebruikt? Gebruik zelf (nog) HTMLArea maar vind dat megabrak, ga binnenkort eens FckEditor gebruiken.

Volgens mij zijn die Java Applets veel beter. Veel stabieler, geen geklooi met JavaScript en het werkt (zo goed als) altijd zolang de JavaVM maar geïnstalleerd is. En daarbij is het door het gebruik van Java een stuk makkelijker aan te passen (gestructureerder etc) dan wanneer er JS gebruikt wordt.

Jammer alleen dat de goede Java Applet editors mega duur zijn, en om zo'n ding nou zelf te maken.... Kan wel een flinke berg Java, maar volgens mij kost dit teveel tijd.

[Verwijderd]

Ik snap niet helemaal hoe Java editors precies werken. Welk mechanisme zorgt ervoor dat er HTML uitgespuugd kan worden? In JavaScript is dat gewoon een IFRAME dat content editable is, waarna de browser engine er wel iets van bakt.

Java is wel erg traag, van die superlompe componenten krijg je dan. Javascript is qua laden veel sneller.

[chris]

Verwijderd schreef op 10 september 2004 @ 10:59:
Ik denk dat veel cms'en ze ook weer niet te pas en te onpas gebruiken. Met wat slimme formulieren kan je dezelfde resultaten krijgen. Maar dan weet men zeker dat het goed is. Met een html-editor blijft het afhangen van de persoon die invoert. En ook voor de invoerder is het soms makkelijk om via een bepaalde structuur te werken.

Klopt, maar voor sommige klanten moet het heel erg simpel (ze zijn alleen MS-Word gewend) en willen ze toch heel veel mogelijkheden. Dan is zoiets ideaal: ze kunnen lekker zelf hun achtergrond roze en NOG grotere kopjes en daar weer een gecentreerde paragraaf: ook met slimme formulieren ben je daar erg lang mee bezig. Ik zet zelf bij zo'n editor standaard alleen de <b>, <u>, <i> en <a> knopjes aan, dan kunnen ze vrijwel niets upfucken, maar als ze dan beginnen te zeiken gaan meteen alle knopjes aan. En nee, je wilt die website 2 maanden later echt niet meer bekijken.

[Verwijderd]

Gisteren een discussie met chem gehad op irc. Hij is van mening dat je alle "Word-horor" gewoon moet strippen. Alle zut eruit halen. Dus ook tabellen. Ik denk dat je met een stel RegExen een boel kan oplossen!

Over tabellen invoegen. Ik ben nu bezig met tabel cell sleep algoritme voor IE en Gecko. Erg leuk om mee te pielen.
Je vroeg oplossingen die ik gevonden had. Nou, je moet dus een alg verzinnen waarbij je cellen realtime kan slepen. Dat is geen standaard feature, dus moet je een soort hack verzinnen. Geloof me, het is behoorlijk ingewikkeld!
Hoe ik dit doe ga ik niet aan de grote klok hangen, maar denk er zelf eens over na. Ik heb nog geen enkele editor gezien die tabelcellen realtime kan resizen (geen goede, wel brakke oplossingen die er mee kappen als de tabelstructuur wat ingewikkelder wordt...)

[ Voor 44% gewijzigd door Verwijderd op 18-09-2004 10:07 ]

[gvanh]

Wat bedoel je met een cell-sleep algoritme? Dat je de cellen van plaats kunt veranderen binnen de tabel?

[Verwijderd]

Nou, precies wat ik zeg...

Normaal als je een tabel selecteert zie je van die blokjes verschijnen. Maar dat is alleen om de hele tabel te resizen. Ik zorg dus dat je dezelfde blokjes krijgt als je in een cell klikt, waarna je die blokjes kan slepen en daarmee de cell realtime vergroot. Het gaat dus alleen om het aanpassen van de afmetingen, width en height.

[ Voor 12% gewijzigd door Verwijderd op 18-09-2004 10:08 ]

[gvanh]

Aaaah ... dat is wel weer poepend sjeik! Sowieso die editor van jou ziet er goed uit!

[Verwijderd]

offtopic:
Je moet gewoon een aantal dingen in een product stoppen zodat je je onderscheidt van de massa. Tabel cel resizen is zoiets... Dat het een dikke 80 uur werk kost (inc. alg voor invoegen rijen, kolommen, verwijderen overbodig colspan etc), boeit dan niet zo.

[djluc]

Ik heb even snel een testje gemaakt om een tabel snel in te kunnen voeren. Momenteel werkt het alleen in Mozilla omdat de functie om bij de cursor iets in te voeren nog niet crossbrowser is.
http://www.djluc.nl/got/richtext

Ik heb dit even door wat noobs laten testen en die konden er goed mee werken. Ze vonden het eenvoudiger als die in Word omdat ze hun muis gewoon los konden laten Ik heb ze ook laten proberen om de border te verwijderen, wat nog helemaal niet mogelijk is , dit proberen ze met de rechtermuisknop. Daar ga ik dus een menuutje voor maken.

[Verwijderd]

Verwijderd schreef op 18 september 2004 @ 10:15:

offtopic:
Je moet gewoon een aantal dingen in een product stoppen zodat je je onderscheidt van de massa. Tabel cel resizen is zoiets... Dat het een dikke 80 uur werk kost (inc. alg voor invoegen rijen, kolommen, verwijderen overbodig colspan etc), boeit dan niet zo.

No offence, maar wat onderscheid je editor van de andere editors? Je hebt geen enkele functie die ik nog niet ben tegengekomen in andere editors

Een paste of word button lijkt mij persoonlijk het eerste wat ik uit zou schakelen, daar komen ongetwijfeld vragen over van klanten. En verder krijg ik nog heel snel errors, omdat popups geblocked worden, waarom eigenlijk, ik heb je code nog niet debugged. Een popup wordt pas geblocked als de actie die wordt uitgevoerd niet afhankelijk is van een mousedown icm met een mouseup, dat is niet het geval ...

Nietemin vind ik het altijd tof als mensen in Javascript components ontwikkelen, dat is dan weer mijn liefde voor het vak, maar als je echt onderscheidend wilt zijn van andere editors, dan staat bij mij stabiliteit en implementatie snelheid bovenaan.

Je kunt nog zo'n mooi fancy component hebben ontwikkeld, met kleurtjes, geluidjes, functionaliteiten, wizards, etc.. als ik het niet snel kan implementeren of als ik zonder al teveel moeite errors krijg, dan is het al snel delete.. next... Als ik al errors krijg, dan zijn de klanten helemaal snel klaar.


Momenteel is SO Editor van SiteObjects daar heer en meester in. Dat is mijn eerste keuze qua editors. Dat ik geen code voor het implementeren van media kan invoegen neem ik dan maar op de koop toe.

Maar ik zeggen ga zo door, en werk vooral aan stabiliteit, dat is imo voor mij het belangrijkste. Iets wat ze allemaal nog missen.

[ Voor 4% gewijzigd door Verwijderd op 18-09-2004 21:33 ]

[Verwijderd]

Verwijderd schreef op 18 september 2004 @ 21:30:
[...]
...

No offence, maar ik vind je reactie behoorlijk ongenuanceerd. Ik onderscheid mij juist in gemak qua implementatie. Kijk voor de grap eens in de html broncode, enkel een core.nextavenue.js include is voldoende. Bovendien heb je geen gedoe als je een formulier wil verzenden.
Implementatie kán volgens mij niet makkelijker. Paste of Word, tjah, we zullen zien. Mijn glazen bol is momenteel bij de wasserette, dus ik weet niet of ik er vragen over zal krijgen

De fout met de popups zat er idd in, maar die heb ik er nu netjes uitgehaald. Als je blocker de popup blockt, krijg je automatisch een bericht met uitleg over hoe en wat.

Dat ding van SEO gebruikt ook server side taal, dat vind ik opzich jammer. ik onderscheid me door als een van de weinigen puur client side bezig te zijn.

Ook het gemak van uitbreidbaarheid heb ik niet bij andere editors gezien. Dan zullen we al helemaal niet praten over het realtime resizen van tabellen. Dat is wel een functie waar ik echt blij mee ben. Over een maandje of twee zal hij er ook in zitten voor Mozilla.

Ik ben het absoluut met je eens dat een component stabiel moet zijn, maar afgezien het popup foutje, heb ik niets ontdekt. In je post doe je net alsof je nog een waslijst van tig fouten heb.
Dit is nu opgelost... Dan vraag ik je nu om nog een paar instabiele dingen op te noemen zodat ik daaraan kan werken...

/ Edit: vergeten: werkend in Gecko en IE... moet ik nog meer noemen? Trouwens, toggle in so maar eens tussen design -> html -> design. History vergeten... Ze gebruiken blijkbaar geen eigen history object, maar het execCommand. En het is bekend dat die alles "vergeet" nadat je switcht.
Bovendien is die CSS parser echt ruk! Twee keer tekst selecteren, zeg dat het een ondertitel is, heb ik opeens twee geneste h2 tags...

Trouwens, ik onderscheid mij qua onder-de-motorkap. Niet qua features. Die features boeien niet zo. Het gaat er om hoe gemakkelijk nieuwe features geïmplementeerd kunnen worden. En of anderen behalve ik dat ook kunnen. Dat is iets wat ik miste in andere editors.

[ Voor 22% gewijzigd door Verwijderd op 18-09-2004 23:24 ]

[bRight]

anders kun je er altijd nog een paar knoppies uit slopen

[Verwijderd]

Verwijderd schreef op 18 september 2004 @ 22:44:
[...]

No offence, maar ik vind je reactie behoorlijk ongenuanceerd. Ik onderscheid mij juist in gemak qua implementatie. Kijk voor de grap eens in de html broncode, enkel een core.nextavenue.js include is voldoende.

Daarom vroeg ik ook wat je onderscheid was van andere editors, een legitieme vraag aangezien je op je site niet uitgebreid in gaat op wat jou onderscheid van de andere editors.

Mijn vraag is ook zeker niet zo vreemd, gezien de wildgroei van editors, die allemaal dezelfde functionaliteiten bevatten, allemaal beweren open te zijn, en zich natuurlijk allemaal als beste kwalificeren.

Dat ding van SEO gebruikt ook server side taal, dat vind ik opzich jammer. ik onderscheid me door als een van de weinigen puur client side bezig te zijn.

Nee SiteObjects heeft alleen de PHP, ASP.NET en Coldfusion community een extra stap voorwaarts te geven door een serverside tag / component te ontwikkelen voor SoEditor die de declaratie dynamisch uitvoert. Voor de rest is het een clientside component.

Ik ben het absoluut met je eens dat een component stabiel moet zijn, maar afgezien het popup foutje, heb ik niets ontdekt. In je post doe je net alsof je nog een waslijst van tig fouten heb.
Dit is nu opgelost... Dan vraag ik je nu om nog een paar instabiele dingen op te noemen zodat ik daaraan kan werken...

De door mij genoemde instabiliteit zie je terug op bijna alle editors. Ik noemde alleen de bugs op die ik bij jou zo 123 zag. De instabiliteit waarop ik doelde zie je oa terug bij htmlArea.

Bovendien is die CSS parser echt ruk! Twee keer tekst selecteren, zeg dat het een ondertitel is, heb ik opeens twee geneste h2 tags...

Dat zijn inderdaad van die zaken die bij SoEditor niet goed gaan, de forums staan er ook vol van, maar er is wel een ding dat het ding wel doet. Zo werken dat de gebruiker er geen last van heeft.

Trouwens, ik onderscheid mij qua onder-de-motorkap. Niet qua features. Die features boeien niet zo. Het gaat er om hoe gemakkelijk nieuwe features geïmplementeerd kunnen worden. En of anderen behalve ik dat ook kunnen. Dat is iets wat ik miste in andere editors.

Bingo, dat is dan je onderscheid. Jij bepaalt de featureset via XML, andere editors via javascript bools

[ Voor 5% gewijzigd door Verwijderd op 19-09-2004 13:55 ]

[Verwijderd]

offtopic:
Ik weet niet in hoeverre dit onder de spam valt, maar aangezien jij zelf het onderwerp aankaart, ga ik ervan uit dat ik mag doorreageren

Het is inderdaad waar dat op mijn site niet volledig duidelijk is hoe NextAvenue werkt en waarom het zo aantrekkelijk is voor programmeurs. Ik ben nu hard bezig om de site te ontwikkelen die straks de lucht in gaat. Daar zal ik veel meer informatie geven over de nextavenue API.

Het is jammer (voor mij gunstig), dat geen enkele editor een eenvoudige API heeft om nieuwe extensies toe te voegen. Veel bedrijven hebben best kennis in huis en kunnen echt wel een kleine API van zo'n 25 functies leren.
Zij balen vaak dat ze de editor niet perfect kunnen integreren met hun systeem, denk daarbij aan een afbeelding manager etc. of andere exotische functies die de klant eist.
Dat gegeven en een klein beetje spieken bij Macromedia, heeft mij ertoe aangezet om voor deze aanpak te kiezen. De core is de core en daar hoeft niemand aan te zitten. Geen geduik in honderden regels javascript code. Gewoon een aantal XML bestanden waarin alles gedefinieerd is.
Bovendien is de CSS parser goed. In ieder geval vele malen beter dan andere editors. De code van de parser is trouwens gewoon in te zien, aangezien de parser zelf ook een extensie is. Staat gewoon in toolbar.xml (te zien op de site).
Ik vind ook dat je opties moet inbouwen als ze zeeen van tijd kosten. Zoals het history object en het tabelsleep ding.
Kleine toevoegingen die niet even met een execCommand zijn op te lossen, maar waar workarounds voor gemaakt moeten worden die soms een duizendtal regels code opleveren.

/me neuriet zachtjes: Het zijn de kleine dingen die het doen, die het doen...

Ik wil nummer één worden qua wysiwyg componenten. De plannetjes voor de volgende core schieten al door mijn hoofd, maar eerst versie twee goed op poten zetten.