GPL javascript online wysiwyg editor?

maandag 16 juni 2003 22:14

Q schreef op 16 June 2003 @ 22:02:
Een java editor is ook out of the question omdat dit teveel van de pc vraagt.

wat draai je dan? een P90 ofzo? Er bestaan HOPEN java editors die allemaal best werken en helemaal niet 'zwaar' zijn. Wel oppassen voor degene die Swing gebruiken die zijn wel groot. (heb er al zien staan van 64KB, met image uploading, etc, etc). Cross Platform heb je geen keus. Nu ja als je geen Images moet hebben kun je nog wel Flash MX gebruiken...

Acties:

maandag 16 juni 2003 22:20

Au Contraire Mon Capitan!

Topicstarter

Eigenlijk alleen voor mij zelf:
Functionele eisen:

Must have:

- Tekst van bepaalde stylesheet opmaak voorzien, zoals bold en italic
- Plaatje toevoegen

Dan ben ik eigenlijk al tevreden.

Should have:

- Link maken van geselecteerte tekst

Zoeiets als bitfluxeditor is buitengewoon mooi en geavanceerd maar veel te complex voor mij en om te integreren in mijn site.

Acties:

maandag 16 juni 2003 22:22

Reist de wereld rond

http://www.ektron.com/ewebwp.cfm?doc_id=2350 dan?
[google=flash wysiwyg html editor] geeft zat results.

Klaar voor een nieuwe uitdaging.

Acties:

Vurabes

Homo Sapiens Informaticus

Deze is ook goed, vooral met tabellen:
http://www.openmymind.net/products/ewe/index.php

On a clear day you can C#

maandag 16 juni 2003 22:24

Acties:

maandag 16 juni 2003 22:30

*zucht*

Deze zoektocht heb ik destijds ook gevoerd. Ik kwam op een aantal mogelijkheden:

- Een gratis IE-only oplossing gebruiken en deze flink strippen (we wilden hele andere dingen dan die standaard dingen aanboden)
- Een commerciele Java versie gebruiken. Voordeel was dat het zeer uitbreidbaar en platformonafhankelijk was. Nadeel was de prijs en de traagheid.
- Zelf een editor schrijven die alleen die features had die wij wilden. Voordeel was dat we alles zo konden maken als we zelf wilden. Nadelen waren dat het dan dus op basis moest van het MSHTML component (IE-only) en de tijd/geld die dit zou gaan kosten in ontwikkeling.

We hebben uiteindelijk voor de laatste optie gekozen en hebben hier geen spijt van. Klanten werken allemaal wel met IE5+ en voor een backend systeem is een dergelijke eis ook niet zo heel vreemd. De applicatie is op snelheid geoptimaliseerd en geeft de gebruiker door ons gecontroleerde mogelijkheden, ipv het hele scala aan richtext-zut.

De dingen die jij noemt zijn dermate simpel te implementeren met het MSHTML component dat ik dat ook lekker zelf zou maken. Over de Mozilla versie zou ik me niet zo druk maken, die werkt nog erg buggy en is imho momenteel zonde van de tijd (welke klanten werken nou met Mozilla en als ze dat doen dan kunnen ze voor het CMS best even IE pakken).

Acties:

Verwijderd

http://www.revjon.com/ftb/ kun je misschien ook aanpassen, er wordt een mozilla compatibele versie van gemaakt als ik de website mag geloven.

maandag 16 juni 2003 22:43

Acties:

maandag 16 juni 2003 22:45

Reist de wereld rond

Bosmonster schreef op 16 juni 2003 @ 22:24:
Klanten werken allemaal wel met IE5+

nofi, maar ik heb een Mac. En nu? Geen klant bij jullie dus?

Klaar voor een nieuwe uitdaging.

Acties:

Willem

Met dank aan Bosmonster voor de uitgebreide uitleg. Als je aan de gang wilt met dit soort dingen zul je je of moeten verdiepen in JS, of goed af moeten kijken van anderen.

Op verzoek -terecht- weer open, maar zorg ervoor dat dit topic niet de kant opgaat van het scriptrequesten, maar richting discussie over de verschillende mogelijkheden van het e.e.a. hier besproken.

[ Voor 37% gewijzigd door Willem op 16-06-2003 23:00 ]

Motor (of auto) onderhoud bijhouden

maandag 16 juni 2003 23:07

Acties:

maandag 16 juni 2003 23:09

Reist de wereld rond

Om er meteen een on-topic slinger aan te geven dan: welke editors kennen jullie, en welke voor/nadelen hebben die?

Zelf heb ik met wat code van mozilla.org een JS editor geschreven die wat eenvoudige RML truukjes kan (tabelletje, bold/italic, lijsten, etc.), en dankzij wat mozilla-bugfixes recentelijk ook blokken tekst kan 'wrappen', wat tegelijk ook in IE werkt. Met een beetje mazzel werkt het in elke DOM-compatible browser.

Daarnaast gebruiken we voor het CMS de contentEditable van IE5.5+, en dat is 1 stuk ellende. De output is echt absurd, en copy/pasted tekst uit Word (ok, vragen om problemen

) zorgt voor tekst die nooit meer in orde te krijgen is (dubbele linespacing etc.).

Midas is een mooi begin/alternatief, ik hoop dat het wat gaat worden, het is nu leuk om te testen maar verder niet; wel is de output van veel grotere kwaliteit dan MSHTML, wat voor bv server-side talen eenvoudiger te parsen is.

Klaar voor een nieuwe uitdaging.

Acties:

maandag 16 juni 2003 23:11

*zucht*

chem schreef op 16 juni 2003 @ 22:43:
[...]

nofi, maar ik heb een Mac. En nu? Geen klant bij jullie dus?

Jawel hoor, maar het CMS werkt niet op een Mac

En waarschijnlijk is het voor de klant goedkoper een pc'tje aan te schaffen dan ons een Mac-compatible versie te laten maken

Gelukkig komen we deze zaken in de parktijk niet (of erg zelden) tegen. En mocht je dan een klant verliezen omdat ie niet de beschikking heeft over een pc dan is het jammer. Het is voor ons niet rendabel de compatibiliteit te bouwen. We runnen een bedrijf, geen gesubsidieerde instelling

Misschien als Midas volwassen wordt en vergelijkbaar met het MSHTML component dat het dan bruikbaar wordt. Sterker nog, als Midas goede html gaat genereren (en in vergelijking met MSHTML is dat niet zo moeilijk lijkt me

) dan hebben we er al aan gedacht om het CMS daarop te baseren en de klant simpelweg een Mozilla installatie mee te geven

CMS als homepage en klaar.. run dat programma maar als je wilt CMS'en

edit:

Grotendeels wat chem tegelijkertijd aan het typen was over Midas dus

[ Voor 9% gewijzigd door Bosmonster op 16-06-2003 23:11 ]

Acties:

maandag 16 juni 2003 23:13

Reist de wereld rond

Bosmonster schreef op 16 June 2003 @ 23:09:
[...]

Jawel hoor, maar het CMS werkt niet op een Mac En waarschijnlijk is het voor de klant goedkoper een pc'tje aan te schaffen dan ons een Mac-compatible versie te laten maken

Gelukkig komen we deze zaken in de parktijk niet (of erg zelden) tegen. En mocht je dan een klant verliezen omdat ie niet de beschikking heeft over een pc dan is het jammer. Het is voor ons niet rendabel de compatibiliteit te bouwen. We runnen een bedrijf, geen gesubsidieerde instelling

Daar heb je wel gelijk in uiteraard, was ook wel een beetje een open deur intrappen

Maar voor mij is het bv vrij irritant als ik thuis geen typo op onze of een andere site kan aanpassen, omdat ik anders in een DB moet gaan zitten :#$&@

Misschien als Midas volwassen wordt en vergelijkbaar met het MSHTML component dat het dan bruikbaar wordt. Sterker nog, als Midas goede html gaat genereren (en in vergelijking met MSHTML is dat niet zo moeilijk lijkt me ) dan hebben we er al aan gedacht om het CMS daarop te baseren en de klant simpelweg een Mozilla installatie mee te geven

Zoals Midas er nu uitziet, gaat het met grote schreden vooruit. Ik ben vooralsnog van plan een parser voor de Midas output te schrijven, zodat dit dmv RML na te bouwen is.

Klaar voor een nieuwe uitdaging.

Acties:

Willem

Op zich het feit dat de klant niet over een Mac zou beschikken staat wat mij betreft volledig los van het feit dat het hem op de een of andere manier een PC zou kosten..

Verzien dan een oplossing als tegen de klant te zeggen dat het wellicht niet geheel onverstandig zou zijn om een Mozilla of andere Netscapen / Gecko achtige browser te downloaden waarin het CMS wel te zien is.... ipv duur en onnodig te investeren

Motor (of auto) onderhoud bijhouden

maandag 16 juni 2003 23:14

Acties:

maandag 16 juni 2003 23:18

*zucht*

willem169 schreef op 16 June 2003 @ 23:13:
Op zich het feit dat de klant niet over een Mac zou beschikken staat wat mij betreft volledig los van het feit dat het hem op de een of andere manier een PC zou kosten..

Verzien dan een oplossing als tegen de klant te zeggen dat het wellicht niet geheel onverstandig zou zijn om een Mozilla of andere Netscapen / Gecko achtige browser te downloaden waarin het CMS wel te zien is.... ipv duur en onnodig te investeren

Als het CMS daar op zou werken wel.. maar helaas is Midas daar in huidige staat dus nog niet aan toe

Ik hoop ten zeerste dat er voor 1.5 serieus een editor mee te bouwen zal zijn.

De andere optie was dus de Java versie.. maar helaas is Java nog steeds extreem traag clientside. Als klanten zo iedere pagina moesten gaan editen (of vaak alleen content-componenten), dan zouden ze op den duur helemaal gek worden denk ik.. Ik in ieder geval wel

[ Voor 16% gewijzigd door Bosmonster op 16-06-2003 23:15 ]

Acties:

deviltje

Misschien is HTMLArea een oplossing..
er is een versie 2 deze werkt alleen in IE
ze zijn nu druk bezig met een versie 3, deze is dus ook te gebruiken in mozilla ( vanaf 1.3, nog niet in mozilla firebird ( phoenix ))

http://www.interactivetools.com/products/htmlarea/

hij is nog gratis ook..

Iedereen die in telekinese gelooft, steek a.u.b. mijn hand op

maandag 16 juni 2003 23:19

Acties:

maandag 16 juni 2003 23:24

...

Is een Flash Rich Text editor dan misschien een optie?

Werkt iig consistent op verschillende browsers EN platformen...

"You're only as good, as what you did last week."

Acties:

maandag 16 juni 2003 23:37

Au Contraire Mon Capitan!

Topicstarter

Waarom geen Java?

Mijn site is Links en Lynx compatible. Dat wil ik zo houden. Ik wil vanuit de rimboe op een aftandse pc bij wijze van spreken nog met de site overweg kunnen zonder enige impact op performance of wat dan ook. Ik wil grip op mijn code houden. Ik kan geen java en heb geen interesse in deze taal omdat ik er geen nut voor heb verder. HTML, PHP wel en nu javascript dus ook.

Iedere regel code van mijn site is uit mijn vingers gekomen en ik denk ook bij dit verhaal dat het er op neer zal komen dat ik een voorbeeld na zal gaan bouwen in javascript, als ik die rottaal ooit onder de knie krijg.

--> http://www.openmymind.net/products/ewe/index.php
Prima, maar ondersteund weer geen mozzila!!!!

Omdat als je alleen maar puur javascript gebruikt stel je geen eisen aan de performance van de pc, internetverbinding (geen dikke classes downloaden) en is het absoluut crossplatform, ook een vereiste wat mij betreft.

Ik ben blij dat dit topic toch open mag blijven, ik zie ook dat er toch een hoop mensen zijn die ook met dit probleem worstelen.

Acties:

dinsdag 17 juni 2003 00:12

Reist de wereld rond

oh,when? schreef op 16 June 2003 @ 23:19:
Is een Flash Rich Text editor dan misschien een optie?

Werkt iig consistent op verschillende browsers EN platformen...

hmz, onder OS X met Camino en Flash wist-ik-het-maar welke versie, is het niet echt fijn werken - selecteren werkt bv raar, en het geheel is onnodig traag.
Verder mis ik ook het plaatsen van afbeeldingen, tabellen etc.

Klaar voor een nieuwe uitdaging.

Acties:

dinsdag 17 juni 2003 00:24

*zucht*

chem schreef op 16 juni 2003 @ 23:37:
[...]

hmz, onder OS X met Camino en Flash wist-ik-het-maar welke versie, is het niet echt fijn werken - selecteren werkt bv raar, en het geheel is onnodig traag.
Verder mis ik ook het plaatsen van afbeeldingen, tabellen etc.

En je zit met het feit dat als je er wat op wilt aanpassen (en dat wil je, bijvoorbeeld combineren met media-library in je CMS of koppelen van andere database content) je dan Flash guru moet zijn om wat voor elkaar te krijgen.

Acties:

dinsdag 17 juni 2003 11:01

als je client WEL de swing libaries (ie Java 1.4.x effe wil installeren) laat installeren (elke machine kan dat) dan kun je 'redelijk' eenvoudig een HTML editor gebruiken (JEditorPane). Wij gebruiken zo'n geval clientside in een Java App, maar het kan evengoed als applet (mits de Java 2 dus) - qua snelheid valt er ook niets op aan te merken (ik werk op 400Mhz Celeron) en kan rustig met stylesheets enzovoorts weg. De code is ook ineens HTML compliant en je kan er in theorie ook alles in steken. (nou ja typisch v4 spul).
Onze editor hebben we gebaseerd op

http://www.lightdev.com/template.php4?id=3

deze is opensource GPL'ed - aangezien ik erg veel moest doen (ie mini Dreamweaver) heb ik die gast ook wat hulp gegeven want zijn code was niet bijster.

Maar je gaat er veel tijd insteken die je wellicht beter kan geven aan een goedkoop commercieel gevalletje (hadden wij ook moeten doen)

Acties:

dinsdag 17 juni 2003 11:04

Reist de wereld rond

Die Java ding is wel mooi. Webstart, en werkt snel. Uiteraard (of helaas) niet zo flexibel als een 'echte' HTML editor, maar toch een goed begin.

Vraag ik me echter toch af, hoeveel tijd het kost een 100% wysiwyg editor voor bv RML te maken.

Klaar voor een nieuwe uitdaging.

Acties:

dinsdag 17 juni 2003 11:09

*zucht*

hobbit_be schreef op 17 June 2003 @ 00:24:
als je client WEL de swing libaries (ie Java 1.4.x effe wil installeren) laat installeren (elke machine kan dat) dan kun je 'redelijk' eenvoudig een HTML editor gebruiken (JEditorPane). Wij gebruiken zo'n geval clientside in een Java App, maar het kan evengoed als applet (mits de Java 2 dus) - qua snelheid valt er ook niets op aan te merken (ik werk op 400Mhz Celeron) en kan rustig met stylesheets enzovoorts weg. De code is ook ineens HTML compliant en je kan er in theorie ook alles in steken. (nou ja typisch v4 spul).
Onze editor hebben we gebaseerd op

http://www.lightdev.com/template.php4?id=3

deze is opensource GPL'ed - aangezien ik erg veel moest doen (ie mini Dreamweaver) heb ik die gast ook wat hulp gegeven want zijn code was niet bijster.

Maar je gaat er veel tijd insteken die je wellicht beter kan geven aan een goedkoop commercieel gevalletje (hadden wij ook moeten doen)

Erg mooi.. maar de snelheid gaat ook meer om het initialiseren van de applet op iedere pagina, niet zozeer om de 'werk-snelheid'. Verder is mijn kennis van Java te beperkt deze editor aan te passen aan mijn wensen. Dan zijn de paar regels javascript om een browsercomponent aan te spreken een stuk eenvoudiger.

Acties:

jonggoud.nl

@>--"--,--{

Als ik niet gebruik maak van de ingebouwde HTML editor van Nextensio gebruik ik http://www.xefteri.com/articles/apr202002/default.aspx je kan 'm erg makkelijk uitbreiden naar alle opties die je wilt. Aan een DB koppelen etc.

Er is echter een probleem: iframes, hij werkt dus niet met Netscape

[ Voor 15% gewijzigd door jonggoud.nl op 17-06-2003 11:10 ]

Nieuw (groots) project, mail me wat je er van vindt
Tevens in het bezit van een beeldschone vriendin

dinsdag 17 juni 2003 11:40

Acties:

dinsdag 17 juni 2003 13:15

offtopic:
[quote]chem schreef op 17 juni 2003 @ 11:01:
Vraag ik me echter toch af, hoeveel tijd het kost een 100% wysiwyg editor voor bv RML te maken.[/quote]

wat is RML?

Tja het duurt wel lang allemaal - vooral omdat een editor in feite meer moet kunnen dan de browser. My hat of naar Dreamweaver (wel traag op mijn bakkie maar kom). Persoonlijk zou ik de client heel weinig opties geven. Hoewel je in theorie met tabellen zou kunnen werken bieden we die niet aan. Ook bieden we geen enkele font optie aan behalve een paar 'Styles'. Tot dusver hebben ze niet geklaagd. Let wel de hele site werkt met XSL dus als iets in een tabel moet staan word dat opgevangen door een RDMB editor. (met of zonder html als content).

Bosmonster:
Ja die rot startup tijd ook van een applet he - naar't schijnt kun je in 1.4.2 wel gebruik maken van een shared VM die dan weer helemaal niet moet worden opgestart.

Zou leuk zijn als DOM/JS overal werkt maar dat is zo'n kleine kans - Persoonlijk zou ik liever per project werken: als de client allemaal IE bakjes heeft waarom dan niet de ActiveX route gaan, enzovoorts. Je code moet gewoon kunnen pluggen tussen de editors.

Voor echt grote CMS (of IT Solution) vonden we een Browser Only Approach onhaalbaar (met veel records enzovoorts). Tenzij je het dan weer in een applet/webstart of activex gooit

Acties:

2

Tot nu toe het beste (of iig meestbelovende) wat ik ben tegengekomen:

http://mozile.mozdev.org

dinsdag 17 juni 2003 19:24

Acties:

dinsdag 17 juni 2003 19:27

Au Contraire Mon Capitan!

Topicstarter

JAAAAH

Volgens mij is dit precies wat ik zoek:

http://www.interactivetoo...documentation.html#intro2

Open source, gratis etc en puur javascript.

Ik hoop dat jullie er ook wat aan hebben.

Acties:

dinsdag 17 juni 2003 19:30

Reist de wereld rond

Q - jammer dat-ie niet werkt hier.

Klaar voor een nieuwe uitdaging.

Acties:

dinsdag 17 juni 2003 19:41

*zucht*

Q schreef op 17 June 2003 @ 19:24:
JAAAAH

Volgens mij is dit precies wat ik zoek:

http://www.interactivetoo...documentation.html#intro2

Open source, gratis etc en puur javascript.

Ik hoop dat jullie er ook wat aan hebben.

Dan is richtext stukken beter imho. Kun je tabellen tenminste nog per cell resizen enzo en rijen toevoegen e.d.

Acties:

woensdag 18 juni 2003 03:13

Au Contraire Mon Capitan!

Topicstarter

chem schreef op 17 June 2003 @ 19:27:
Q - jammer dat-ie niet werkt hier.

Deze werkt wel met mozilla:

http://www.interactivetoo...mlarea3_demo/example.html

De 3.0 alpha werkt ook met mozilla. de oudere versies niet.

De 3.0 haal je hier weg --> bovenste post heeft onderaan een attachment...

Dan is richtext stukken beter imho. Kun je tabellen tenminste nog per cell resizen enzo en rijen toevoegen e.d.

Dit werkt niet bij mij in mozzila. Bovendien voldoet htmlarea precies aan mijn wensen.

[ Voor 19% gewijzigd door Q op 17-06-2003 19:46 ]

Acties:

Verwijderd

die htmlarea werkt niet in netscape 7, hij zegt: "sorry, you need at least mozilla-1.3 alpha"
Dus dan moet de klant wel de allerlaatste versie hebben.

Ik ben zelf ook aan t brainstormen over een wysiwyg editor, maar mijn grootste probleem is t copy & paste verhaal, dit gebeurt bijna overal met speciale IE dingen, die nergens anders werken.
Nu kan je het wel stiekem oplossen, door gewoon ergens verborgen een textarea neer te planten en die eeuwig de focus geven etc, maar in zo'n geval kun je geen tekst met opmaak copy & pasten. Wel binnen dezelfde tekst, maar niet vanuit bijv een ander browservenster of iets als Word. (het weggooien van de overbodige Word tags is een ander verhaal).

In principe is alles qua de wysiwyg editors wel mogelijk in de verschillende browsers, behalve t copy paste verhaal. Feitelijk is t alleen stukken makkelijker in IE dan in Mozilla om te maken (heel veel functionaliteit zit gewoon standaard ingebakken in IE, met mozilla moet je veel dingen gaan simuleren ensow, zoals de cursor, en selectie etc.)

Liefste zou ik t geheel gewoon in flash maken (omdat ik dan een hoop realtime bewerkingen zou kunnen uitvoeren zonder van pagina te wisselen etc.), maar dan heb je weer dingen als tabellen die niet ondersteund worden. (het invoegen van plaatjes is me al gelukt via een omweggetje)

Zelf ben ik er nog niet uit wat nu ideaal zou zijn, ik ga nog even kijken naar java, maar daar ben ik toch persoonlijk wat terughoudend in, want mijn java ervaring beperkt zich tot één trimester Technische Informatica, en daar heb ik niet echt genoeg ervaring opgedaan om een editor te kunnen schrijven. Plus dan nog het feit dat het ietwat trager is en er dingen opgestart en geinstaleerd moeten worden (ok met flash moet dat ook, maar dat staat vaak al op computers, en dat hoeft niet elke keer geïnitialiseerd te worden, althans dat duurt niet zo lang)

woensdag 18 juni 2003 09:09

Acties:

woensdag 18 juni 2003 09:25

...

Eigenlijk vindt ik het opvallend dat iedereen zo krampachtig aan HTML vast blijft houden. Toegegeven, wel versterkt en gebruik makend van Javascript ( DHTML ) maar nog steeds HTML. En HTML is toch bij uitstek gemaakt voor het presenteren van data in een document flow, terwijl een toepassing zoals deze toch meer zou profiteren als er gebruik wordt gemaakt van technieken gericht op applicaties, waardoor je ook de voordelen ( GUI toolset, runned in de context van de gebruiker etc ) hebt. DHTML biedt in dit opzicht weinig mogelijkheden, en zit daarnaast altijd vast aan de implementatie in de browser, en de enige wijd verspreide oplossingen zijn Flash ( MX ) en Java ( icm Webstart ).

Eigenlijk verdient dit een draadje op zichzelf, misschien bak ik wel een mooie post...dit was even een constatering.

[ Voor 14% gewijzigd door oh,when? op 18-06-2003 09:11 ]

"You're only as good, as what you did last week."

Acties:

woensdag 18 juni 2003 09:30

*zucht*

Verwijderd schreef op 18 June 2003 @ 03:13:
[...] copy/paste verhaal [...]

Das onzin.. copy/paste commando's zijn in IE heel gemakkelijk af te vangen en te converteren naar text (paste as text is standaard feature die je kunt forceren). Niks geen geneuzel met textarea's of wat dan ook benodigd. Handiger nog is om een simpele functie te schrijven die de html die je paste voor je opschoont, maar ook dit is simpel in het copy/paste verhaal te implementeren.

oh,when? schreef op 18 juni 2003 @ 09:09:
Eigenlijk vindt ik het opvallend dat iedereen zo krampachtig aan HTML vast blijft houden. Toegegeven, wel versterkt en gebruik makend van Javascript ( DHTML ) maar nog steeds HTML. En HTML is toch bij uitstek gemaakt voor het presenteren van data in een document flow, terwijl een toepassing zoals deze toch meer zou profiteren als er gebruik wordt gemaakt van technieken gericht op applicaties, waardoor je ook de voordelen ( GUI toolset, runned in de context van de gebruiker etc ) hebt. DHTML biedt in dit opzicht weinig mogelijkheden, en zit daarnaast altijd vast aan de implementatie in de browser, en de enige wijd verspreide oplossingen zijn Flash ( MX ) en Java ( icm Webstart ).

Eigenlijk verdient dit een draadje op zichzelf, misschien bak ik wel een mooie post...dit was even een constatering.

Als ik de mogelijkheden bekijk dan is de DHTML oplossing simpelweg de snelste in uitvoer en het simpelst te implementeren. DAAROM is dat momenteel de beste oplossing. De Flash-versies hebben als nadeel dat ze vaak erg beperkt zijn in hun mogelijkheden of extra plugins vereisen en lastig aan te passen/uit te breiden zijn. Java versies zijn in principe hele goede oplossing, maar vereist Java-kennis (toch ff wat anders dan DHTML) en als grootste nadeel de lange opstarttijden.

Kheb voor ons CMS zo'n beetje iedere beschikbare editor onder de loep genomen, DHTML versies, Flash versies en Java versies, maar geen kon tot nog toe tippen aan een DHTML versie. Het MSHTML component werkt gewoon precies zoals Word en is super flexibel en gemakkelijk te beinvloeden.

Als je het mij vraagt heb je zelf een beetje erg beperkte visie op (D)HTML. Ik zie daar persoonlijk nog meer toekomst in dan in een Flash of clientside Java.

[ Voor 64% gewijzigd door Bosmonster op 18-06-2003 09:34 ]

Acties:

Verwijderd

I zie vaak de discussie hoe je het beste een CMS kunt bouwen en heb verschillende varianten langs zien komen, en aan sommige een steentje bijgedragen: JAVA, C#, HTML en javasscript in combi met PHP, ASP of PHP. Maar wat deze editors allemaal hadden waren de uitgebreide opmaak functionaliteiten,m wat in mijn ogen nog steeds teveel van het goede is.
CMS betekend cocntent mamagement systeem, en dit heeft dus niks met de opmaak te maken. Mensen moet alleen content kunnen invoeren en frontend word deze dmv. stylesheet of iets anders goed uitgepoept. Ik wil niet dat mensen controle krijgen over de opmaak van de website, mooie magenta kleur text hier in grootte 18px, en daar een BMP uitlijnen naar rechts etc. En vervolgens is van het design van de website niks meer te herkennen ...

Nee een CMS dient ervoor dat content in te kloppen valt.

Wat het verhaal van Owen betreft, ben ik het helemaal eens. HTML is ontworpen om informatie te presenteren. Tabellen zijn gemaakt voor ook echt tabelinformatie, de headers voor de koppen etc. Wanneer je een internetpagina wilt opmaken dan dien je niet tabellen te gebruiken, maar XHTML (div's met CSS). En dan spreekt het ook voorzich dat je een CMS, hoe simpel of uitgebreid, niet kan maken in HTML met javasscript, maar dat een programma als Flash veel meer mogelijkheden bied. Zeker met de komst van MX biedt het programma uitgebreide mogelijkheden voorhet maken van dit soort toepassingen, en de komst van versie 7 van Flash zal deze mogelijkheden alleen nog maar uitbreiden.

woensdag 18 juni 2003 09:37

Acties:

woensdag 18 juni 2003 10:59

*zucht*

Een CMS is voor content, dat klopt. Maar je wilt een klant wel de mogelijkheid bieden zijn eigen site enigszins bij te houden. Dan heb ik het niet over fonts, fontgroottes en font-kleuren. Dit zijn bogus opties en moet je gelijk uitzetten. Net als html-view, leuk voor een developer, maar een klant is daar niet in geinteresseerd.

Wat echter WEL van belang is voor een CMS is dat een klant zelf plaatjes kan invoegen, zijn gegevens kan opmaken middels tabellen en een ander aantal opties (bulltlists e.d.) en koppelingen kan leggen tussen zijn content (links). Want wat is een site zonder koppelingen?

Acties:

Verwijderd

Precies, maar voor een plaatje uploaden heb ik geen javascript/html nodig, maar dat doe ik serverside. Ik wil niet gtaag dat een klant tabellen kan maken, zodat hij een content vlak even opdeeld in 3 kolommen omdat het in zijn ogen het beste is. Opsommingen etc. is logisch om die erin te zetten, en dat vind ik ook meer content dan opmaak van de content, en hiervoor hoef je dan ook geen ingewikkeld en duur systeem te kopen. Dit is namelijk niet al te moeilijk om zelf op te lossen.

woensdag 18 juni 2003 11:09

Acties:

simon

Verwijderd schreef op 18 June 2003 @ 10:59:
Precies, maar voor een plaatje uploaden heb ik geen javascript/html nodig, maar dat doe ik serverside. Ik wil niet gtaag dat een klant tabellen kan maken, zodat hij een content vlak even opdeeld in 3 kolommen omdat het in zijn ogen het beste is. Opsommingen etc. is logisch om die erin te zetten, en dat vind ik ook meer content dan opmaak van de content, en hiervoor hoef je dan ook geen ingewikkeld en duur systeem te kopen. Dit is namelijk niet al te moeilijk om zelf op te lossen.

Ik heb mijn vraagtekens bij zo'n idee, want wiens site is het nu?

|>

woensdag 18 juni 2003 11:14

Acties:

woensdag 18 juni 2003 11:28

Reist de wereld rond

Simon schreef op 18 June 2003 @ 11:09:
[...]

Ik heb mijn vraagtekens bij zo'n idee, want wiens site is het nu?

Idd, en dat heeft ook een relatie naar de grootte van de site: kleine sites die een eenvoudig CMS willen, willen *juist* die 'gadgets', maar verwachten vv dat de devvers van de site de MSHTML meuk kunnen verwerken (dat is ook wel logisch, maar is helaas niet goed mogelijk).

Grote corperate sites zullen toch aan een strakkere layout vastzitten, waar het idd een kwestie is van inhoud kloppen. En een consultant van de CMS boer, uiteraard met ditto tarief per uur om wijzigingen aan te brengen.

Klaar voor een nieuwe uitdaging.

Acties:

woensdag 18 juni 2003 11:46

*zucht*

Verwijderd schreef op 18 juni 2003 @ 10:59:
Precies, maar voor een plaatje uploaden heb ik geen javascript/html nodig, maar dat doe ik serverside. Ik wil niet gtaag dat een klant tabellen kan maken, zodat hij een content vlak even opdeeld in 3 kolommen omdat het in zijn ogen het beste is. Opsommingen etc. is logisch om die erin te zetten, en dat vind ik ook meer content dan opmaak van de content, en hiervoor hoef je dan ook geen ingewikkeld en duur systeem te kopen. Dit is namelijk niet al te moeilijk om zelf op te lossen.

Tabellen zijn daar ook niet voor en uit ervaring weet ik dat klanten ze daar ook niet voor gebruiken (voor hen zijn tabellen nog steeds tabellen).

Maar een klant moet wel een tabelletje van prijzen in zijn site kunnen zetten oid imho. En plaatjes kan ik ook wel los uploaden, maar hoe kan een klant dan kiezen waar dat ding moet komen?

Het blijft content en het moet niet te uitgebreid worden, maar een plaatje en een tabelletje voor gegevens zie ik als minimale functionaliteit.

Acties:

woensdag 18 juni 2003 14:36

Bosmonster schreef op 18 June 2003 @ 11:28:
[...]

Persoonlijk heb ik ook het liefst een echt Content gedoe zonder al te erge opmaak - ik begrijp best dat je een 'tabeltje' wil inzetten , maar ik vraag me af waarom: tabellen voor content zijn meestal data driven (u begrijpt wat ik wil zeggen) en zouden dus al ineens in een andere 'editor' moeten staan (zoals wij toevallig doen

). Grote bedrijven hebben geld voor zo'n seperatie en het aanmaken van een nieuwe 'template' - we hebben geluk hier dat we met Cocoon werken en daar is al de content al mooi met XPath beschikbaar (die XPath kan bijvoorbeeld evengoed data uit een SQL query halen) - onze 'templates' zijn dus zowel extensible als volledige MVC (nu ja: bold tekst enzo zit er nog wel bij, en zelfs een image mag je invoegen in een tekstveld) maar geen tabellen of Left Right Center alignment. Dit alles wordt door XSLT mooi geplonkt naar XHTML.

Voor mijn eigen CMS ga ik gewoon een (HTML based, want Flash kost teveel) mini XML editor (visueel) maken waar ik de data in plonk. Dus zeker geen tabellen as such maar wel een soort

code:

<RDB id="whatever">
    <D><R type="primary" id="name">...</D>
    <C><R><D>4</D>...
</RDB>

waardoor de CMS zelf de persistant storage voor me aanmaakt en dit 'onderdeel' dus kan worden voorgesteld als een phpMyAdmin editorke...

Acties:

Verwijderd

Bosmonster schreef op 18 June 2003 @ 09:25:
[...]

Das onzin.. copy/paste commando's zijn in IE heel gemakkelijk af te vangen en te converteren naar text (paste as text is standaard feature die je kunt forceren). Niks geen geneuzel met textarea's of wat dan ook benodigd. Handiger nog is om een simpele functie te schrijven die de html die je paste voor je opschoont, maar ook dit is simpel in het copy/paste verhaal te implementeren.

Ja dat zeg ik toch ook? In IE zijn daar makkelijke functies voor geschreven, maar die werken niet in andere browsers. Die hebben dat soort dingen uitstaan om beveiligings redenen (t kan bijv. wel in mozilla, maar alleen als t een pagina is die op je locale harde schijf staat, remote werken die functies niet.)
Wel ff lezen wat ik zeg eh

Bosmonster schreef op 18 June 2003 @ 09:25:
Kheb voor ons CMS zo'n beetje iedere beschikbare editor onder de loep genomen, DHTML versies, Flash versies en Java versies, maar geen kon tot nog toe tippen aan een DHTML versie. Het MSHTML component werkt gewoon precies zoals Word en is super flexibel en gemakkelijk te beinvloeden.

Als je het mij vraagt heb je zelf een beetje erg beperkte visie op (D)HTML. Ik zie daar persoonlijk nog meer toekomst in dan in een Flash of clientside Java.

Probleem is wel dat deze oplossing alleen maar werkt in IE, en dat andere browsers er geen ondersteuning voor bieden. Daarom zijn de meeste mensen hier naar alternatieven aan het kijken. Beste zou natuurlijk een volledig cross-platform editor zijn, maar ja, ik begin bang te worden dat ik dan toch echt met java aan de slag zal moeten...

IMHO zul je der wel nooit aan ontkomen dat de client ooit iets zal moeten installeren. Zij het een andere browser, een flash- of java-plugin, etc.
Je kunt natuurlijk bepaalde functionaliteit (in een puur dhtml editor) aan of uitzetten al naar gelang de browser/het besturingssysteem van de gebruiker, maar ook dit is weer niet echt ideaal.

Als HTML beter ondersteund gaat worden in de volgende versie van flash, alsmede een beter copy&paste verhaal, dan wordt t al interessanter, maar tot die tijd heb ik nog geen ideale oplossing gevonden.

woensdag 18 juni 2003 14:40

Acties:

Verwijderd

hmm dat copy/paste/cut verhaal gaat best wel werken hoor en sinds 1.4a zit er ook een Image/tabel resize functie ingebakken (cool effect!!).

http://www.mozilla.org/editor/midasdemo/

Voor een basis Client Side oplossing voldoet Midas al prima en heb je dus toch een X-platform compatible systeem, trouwens de syntax is gelijk aan die van IE, du zo moeilijk is het niet compatible te maken lijkt mij.

[ Voor 6% gewijzigd door Verwijderd op 18-06-2003 14:41 ]

woensdag 18 juni 2003 14:58

Acties:

Verwijderd

mjah ik hou er zelf nooit zo van t nieuwste van t nieuwste te gebruiken, aangezien die clienten niet allemaal van die nerds zoals ik zijn, en ze dus ook niet altijd de laatste upgrades binnen hebben...

Maar zoals ik net al zei, werkt dat copy & paste verhaal niet op een remote server, tenzij je preferences aan gaat passen, wat al met al nogal lastig kan zijn voor de gemiddelde gebruiker (zie de uitleg hier).

woensdag 18 juni 2003 20:32

Acties:

donderdag 19 juni 2003 12:00

Au Contraire Mon Capitan!

Topicstarter

HTMLAREA

Is opzich perfect, maar het vraagt om enige aanpassing, dus behoorlijke kennis van javascript is een must. Als je niet met "harde opmaak" maar met ccs werkt mag je de boel al aanpassen. Bovendien staat het standaardletterype + fontsize niet goed.

Ik hou toch voorlopig maar even de oude methode: content typen in word, copy/pasten naar systeem en dan opmaak er in zetten. Tikje omslachtig maar de tekst wordt niet met ongewenste code (font zaken die niet door mijn css worden geregeld) vervuild.

Misschien als ik tijd heb dat ik mij in javascript ga verdiepen, maar als ik naar de source van dit ding kijk dan wordt ik al moe. ( Q = lui ja)

Acties:

Beekforel

Is eigenlijk geen vis

Ik heb zelf een editor gebouwd, door wat af te kijken van anderen.
Ik ben alleen op zoek naar een goeie manier voor het beheren van plaatjes enzo. Heb wel wat ideetjes, maar echt veel heb ik nog niet gevonden.

donderdag 19 juni 2003 12:17

Acties:

donderdag 19 juni 2003 12:37

...

Verwijderd schreef op 18 June 2003 @ 14:36:
[...]Als HTML beter ondersteund gaat worden in de volgende versie van flash, alsmede een beter copy&paste verhaal, dan wordt t al interessanter, maar tot die tijd heb ik nog geen ideale oplossing gevonden.

define:

• "html beter ondersteund" ( meer tags? css? )
• "betere copy/paste" tekst? plaatjes?

"You're only as good, as what you did last week."

Acties:

Verwijderd

owen; ok:
HTML beter ondersteund:
As in meer tags, zoals tables (ja ben er zelf geen fan van, maar goed, clienten willen t nog wel eens gebruiken)
CSS zou ook leuk zijn, maar dat zie ik zo een twee drie nog niet gebeuren.

Betere copy/paste:
Tekst met opmaak kunnen plakken lijkt me wel prettig. (in een html tekst vlak dan)
Plaatjes in een tekstvlak plakken is onzinnig, alhoewel t me toch wel weer handig lijkt...

Eigenlijk wil ik gewoon een (echt?/goed?) rich tekst veldje hebben in flash

donderdag 19 juni 2003 12:46

Acties:

alienfruit

the alien you never expected

Ik heb dit probleem opgelost door ze gewoon een ActiveX control en/of Java control door hun neus te drukken met me fantastisch (*NOT*) eigen gemaakt editor. Heeft allemaal leuk functies, zoals spellingscontrole, smart tags, draggable images en geheel css wise natuurlijk.

donderdag 19 juni 2003 13:31

Acties:

Verwijderd

offtopic:
ik voorzie wel weer een gezamelijk /14 project aankomen.....

donderdag 19 juni 2003 14:19

Acties:

donderdag 19 juni 2003 15:05

*zucht*

Deze duitse Java-versie heb ik een demo van uitgeplozen. Genereert prima html, maar had wat interactieve vreemdigheden en natuurlijk de trage opstarttijden van de applet. Verder als nadeel dat het een extreem complex stuk software was om uitbreidingen op te maken:

http://www.realobjects.com/

Dit was voor ons destijds een belangrijke concurrent van MSHTML oplossingen

[ Voor 13% gewijzigd door Bosmonster op 19-06-2003 14:21 ]

Acties:

2

Ik begrijp het niet, iedereen komt bij WYSIWYG altijd met van die Word-achtige tekstboxjes aanzetten. Naar mijn idee, als je echt een gebruiksvriendelijke methode wilt hebben om bijv. binnen een CMS pagina's aan te maken of te editen, is het toch veel mooier om de content in het ontwerp/de template te laten verschijnen? Als je dan kijkt naar Mozile, dan ziet dat er toch een stuk beter uit.

donderdag 19 juni 2003 15:10

Acties:

marko77

FCK editor gebruiken wij hier en dat is gratis en werkt uit de kunst! Geen java maar met forms werkt deze.

http://www.fredck.com/FCKeditor/

Mijn rig

donderdag 19 juni 2003 15:31

Acties:

donderdag 19 juni 2003 15:38

*zucht*

2 schreef op 19 juni 2003 @ 15:05:
Ik begrijp het niet, iedereen komt bij WYSIWYG altijd met van die Word-achtige tekstboxjes aanzetten. Naar mijn idee, als je echt een gebruiksvriendelijke methode wilt hebben om bijv. binnen een CMS pagina's aan te maken of te editen, is het toch veel mooier om de content in het ontwerp/de template te laten verschijnen? Als je dan kijkt naar Mozile, dan ziet dat er toch een stuk beter uit.

Nee.. wat ik wil is niet meer dan een soort richtext veld. Het wordt namelijk voor tig andere dingen gebruikt dan een complete pagina op te maken. Bovendien heb je per pagina ook nog veel meer eigenschappen om te wijzigen, welke je dan weer ergens anders onder zou moeten brengen.

Bovendien zou dit niet passen binnen een CMS, want waar blijft dan de rest van je navigatie (of moet je daar weer wat anders op verzinnen). Wat dus de overzichtelijkheid van je hele CMS niet ten goede komt.

Oftewel: enige wat ik zoek is een soort input type="richtext" veld, wat te implementeren is in een CMS.

Acties:

donderdag 19 juni 2003 15:39

...

Bosmonster schreef op 19 June 2003 @ 15:31:
[...]
Oftewel: enige wat ik zoek is een soort input type="richtext" veld, wat te implementeren is in een CMS.

dat zou semantisch gezien net zo'n bull aanvulling op html zijn als we hebben gehad met blink. Net nu we juist met XHTML en de nieuwere proposals nog verder richting complete seperatie gaan van presentatie en beschrijving van data is juist zo'n aanvulling compleet niet op zijn plek.

/edit gelukkig hebben we xforms ( ergens in 2006 ofzo als de browserimplementaties eindelijk common good zijn...weer een reden voor "een andere technologie.."

)

[ Voor 17% gewijzigd door oh,when? op 19-06-2003 15:39 ]

"You're only as good, as what you did last week."

Acties:

Verwijderd

wat mij altijd stoort is dat die editors nog steeds op de oude html manier werken, ervoor er achter en de tekst is opgemaakt terwijl ik dat netjes met css wil doen...

maar op de manier komt er in de select box netjes het juiste font te staan als je de betreffende tekstselecteert, maar nooit de juiste css class... ik zal eens kijken of dat echt niet mogelijk is, volgens mij moet t best wel kunnen, of dat alle editorbouwers die future hebben overgeslagen....

donderdag 19 juni 2003 15:45

Acties:

donderdag 19 juni 2003 15:49

*zucht*

oh,when? schreef op 19 June 2003 @ 15:38:
[...]
dat zou semantisch gezien net zo'n bull aanvulling op html zijn als we hebben gehad met blink. Net nu we juist met XHTML en de nieuwere proposals nog verder richting complete seperatie gaan van presentatie en beschrijving van data is juist zo'n aanvulling compleet niet op zijn plek.

Dat is in feite wat al die developers hier in het topic (mezelf incluis) en heel veel developers op internet willen. Dat het er niet zal komen moge duidelijk zijn. Dus blijven we vastzitten aan halfbakken oplossingen om klanten een stukje content fatsoenlijk op te kunnen maken.

Leuk al die interessante termen en theorieen, maar daar heeft een klant zo weinig aan

Acties:

Beekforel

Is eigenlijk geen vis

Ik geef mijn gebruiker niet de mogelijkheid om zijn font te wijzigen in de editor, dit gebeurt op de page waar de stylesheet aangepast kan worden.
Op die manier hou ik mijn HTML schoon en geef ik de gebruiker toch de mogelijkheid zijn/haar tekst aan te passen. etc wordt nog wel gebruikt btw.

* < dit is een screenshot van mijn CMS - Editor tot nu toe, in gebruik @ een CMS. Ik mis aleen nog het icoontje van het invoegen van een plaatje. Zoals ik al zei ben ik daar mee bezig. Ben al wat interessante dingetjes tegen gekomen, maar moet het nog even implementeren.

[ Voor 44% gewijzigd door Beekforel op 29-04-2022 20:56 ]

donderdag 19 juni 2003 16:20

Acties:

donderdag 19 juni 2003 16:41

...

Bosmonster schreef op 19 juni 2003 @ 15:45:
[...]
Dat is in feite wat al die developers hier in het topic (mezelf incluis) en heel veel developers op internet willen. Dat het er niet zal komen moge duidelijk zijn. Dus blijven we vastzitten aan halfbakken oplossingen om klanten een stukje content fatsoenlijk op te kunnen maken.

Leuk al die interessante termen en theorieen, maar daar heeft een klant zo weinig aan

over dooddoeners gesproken. tuurlijk interesseert het een klant weinig wat en hoe. die wil gewoon aan de slag. alleen wat jij ( en vele developers ) hier willen is gewoon een applicatie ( "rich text editor" ) op internet deployen. gebruik dan ook een technologie die daarvoor geschikt is, en zoek je oplossing dus niet in html of dhtml....want dan blijf je idd met "halfbakken oplossingen" komen.....

lijkt erop alsof ik mijn topic niet eens hoef te openen....jullie komen zelf al met de goede conclusie.

"You're only as good, as what you did last week."

Acties:

InZane

marko77 schreef op 19 June 2003 @ 15:10:
FCK editor gebruiken wij hier en dat is gratis en werkt uit de kunst! Geen java maar met forms werkt deze.

http://www.fredck.com/FCKeditor/

Gebruik ik zelf ook vaak

Ze zijn zelfs zo aardig geweest om er een module(tje) voor ColdFusion voor te maken.

donderdag 19 juni 2003 16:48

Acties:

donderdag 19 juni 2003 18:36

*zucht*

oh,when? schreef op 19 June 2003 @ 16:20:
[...]

over dooddoeners gesproken. tuurlijk interesseert het een klant weinig wat en hoe. die wil gewoon aan de slag. alleen wat jij ( en vele developers ) hier willen is gewoon een applicatie ( "rich text editor" ) op internet deployen. gebruik dan ook een technologie die daarvoor geschikt is, en zoek je oplossing dus niet in html of dhtml....want dan blijf je idd met "halfbakken oplossingen" komen.....

lijkt erop alsof ik mijn topic niet eens hoef te openen....jullie komen zelf al met de goede conclusie.

Er is momenteel nog niks anders dan halfbakken oplossingen. Ook de door jouw zo geopperde Flash-versies zijn halfbakken oplossingen imho, want ze doen niks meer dan een DHTML versie, als ze al bestaan.

Ik sta open voor alle mogelijkheden, er zijn er alleen verdomde weinig

Acties:

Bluestorm

2 schreef op 19 June 2003 @ 15:05:
Ik begrijp het niet, iedereen komt bij WYSIWYG altijd met van die Word-achtige tekstboxjes aanzetten. Naar mijn idee, als je echt een gebruiksvriendelijke methode wilt hebben om bijv. binnen een CMS pagina's aan te maken of te editen, is het toch veel mooier om de content in het ontwerp/de template te laten verschijnen? Als je dan kijkt naar Mozile, dan ziet dat er toch een stuk beter uit.

Natuurlijk is dat mooi... maar zodra je bijvoorbeeld een nieuwsitem wilt bewerken zul je toch in je editmode ook andere velden willen tonen, zoals de samenvatting die misschien op de homepage komt te staan, etc. Dan blijft er van je in-page editing mogelijkheden weinig meer over lijkt me.

Tenminste... dat [ denk / zie / weet ] ik... | Javascript obfuscator | foto's en video's uploaden

donderdag 19 juni 2003 22:04

Acties:

2

Bosmonster schreef op 19 June 2003 @ 15:31:
[...]

Nee.. wat ik wil is niet meer dan een soort richtext veld. Het wordt namelijk voor tig andere dingen gebruikt dan een complete pagina op te maken. Bovendien heb je per pagina ook nog veel meer eigenschappen om te wijzigen, welke je dan weer ergens anders onder zou moeten brengen.

Volgens mij begrijp je me verkeerd. In feite waar ik voor pleit is juist de mogelijkheid om ieder element 'editable' te kunnen maken, zodat de developer zelf uit mag maken hoe hij deze funtionaliteit mag toepassen. Daarom is mozile zo stoer; het is een inline editor, geen gekut met iframes e.d. Zo heb je veel meer vrijheid wat natuurlijk de boel een stuk gebruiksvriendelijker kan maken.

Verder ben ik het enerzijds wel eens met owen dat het loodrecht staat op het hele idee van de omschrijvende structuur, maar anderzijds denk ik dat een attribuut dat aangeeft dat de content van een bepaald element editable is binnen deze filosofie op zich wel kan past, aangezien dit net zo goed als eigenschap gezien kan worden van dit element als alle andere.

Het idee om bijv. flash te gebruiken om hetzelfde te bewerkstelligen is in de commerciele kringen waarschijnlijk een goede oplossing, maar je moet denk ik niet vergeten dat het toch ook een mooi doel is om voor een functionaliteit als deze een goede open standaard te ontwikkelen.

Bluestorm schreef op 19 June 2003 @ 18:36:
Natuurlijk is dat mooi... maar zodra je bijvoorbeeld een nieuwsitem wilt bewerken zul je toch in je editmode ook andere velden willen tonen, zoals de samenvatting die misschien op de homepage komt te staan, etc. Dan blijft er van je in-page editing mogelijkheden weinig meer over lijkt me.

Ik snap niet helemaal hoe dat een tegenargument is. De methode die ik noem geeft juist veel meer vrijheid voor dit soort doeleinden. Je _hoeft_ het ook niet geheel in de layout van een hele pagina te doen.

[ Voor 18% gewijzigd door 2 op 19-06-2003 22:06 ]

donderdag 19 juni 2003 22:16

Acties:

alienfruit

the alien you never expected

Ik houd het erbij gewoon Active/Flash/Java gebruiken hiervoor, omdat ik zelf me Delphi Html Editor al naar ActiveX en Java heb geconverted (same codebase

code -> xml -> transform -> taal

) blijf ik nu gewoon me Java speeltje gebruiken. Altijd al eens scruft hekel gehad aan DHTML/HTML WYISWYG editors

donderdag 19 juni 2003 23:27

Acties:

Bluestorm

2 schreef op 19 June 2003 @ 22:04:
[...]

Ik snap niet helemaal hoe dat een tegenargument is. De methode die ik noem geeft juist veel meer vrijheid voor dit soort doeleinden. Je _hoeft_ het ook niet geheel in de layout van een hele pagina te doen.

Als je echt in-page editing doet... dan neem ik aan dat je alles edit zoals het zichtbaar is op de site... toch?
Maar er zijn dingen zoals nieuwsartikelen etc waarvan verschillende stukjes informatie over verschillende pagina's verdeeld zijn. Dan zou je dus op verschillende pagina's één item moeten bewerken.

Wat ik wil zeggen is dat volgens mij dit soort in-page editing alleen werkt als wat er zichtbaar is ook alles is wat er te editen valt. Zoals bij gewoon platte content.
Als er in 'editmode' zeg maar meer te bewerken valt dan wat je normaal op de site ziet... heb je niets meer aan je in-page editing lijkt me.

Tenminste... dat [ denk / zie / weet ] ik... | Javascript obfuscator | foto's en video's uploaden

vrijdag 20 juni 2003 09:25

Acties:

woensdag 30 juli 2003 14:07

*zucht*

Bluestorm schreef op 19 June 2003 @ 23:27:
[...]

Als je echt in-page editing doet... dan neem ik aan dat je alles edit zoals het zichtbaar is op de site... toch?
Maar er zijn dingen zoals nieuwsartikelen etc waarvan verschillende stukjes informatie over verschillende pagina's verdeeld zijn. Dan zou je dus op verschillende pagina's één item moeten bewerken.

Wat ik wil zeggen is dat volgens mij dit soort in-page editing alleen werkt als wat er zichtbaar is ook alles is wat er te editen valt. Zoals bij gewoon platte content.
Als er in 'editmode' zeg maar meer te bewerken valt dan wat je normaal op de site ziet... heb je niets meer aan je in-page editing lijkt me.

Dat is ook wat ik bedoelde.. als je alleen platte content hebt is kan het geinig zijn, maar over het algemeen bestaat je site uit verschillende componenten, die op tig plekken hergebruikt worden. Dan blijft van het idee ongeveer over dat je je stukje werkelijke content kunt beheren in de layout van de pagina. Nou wowser, dat is geil, maar zo functioneel als het paars op GoT.

alienfruit schreef op 19 juni 2003 @ 22:16:
Ik houd het erbij gewoon Active/Flash/Java gebruiken hiervoor, omdat ik zelf me Delphi Html Editor al naar ActiveX en Java heb geconverted (same codebase code -> xml -> transform -> taal ) blijf ik nu gewoon me Java speeltje gebruiken. Altijd al eens scruft hekel gehad aan DHTML/HTML WYISWYG editors

Geweldig.. Het liefst zie ik ook een ActiveX versie (snel en toch onbeperkte mogelijkheden doordat je een 'echte' programmeertaal kunt gebruiken ipv Flash oid)! Maar helaas is mijn kennis daar te beperkt in

[ Voor 22% gewijzigd door Bosmonster op 20-06-2003 09:27 ]

Acties:

oZy

bescheiden kickje,

Ik ben ook opzoek naar een dergelijk systeem. Het probleem wat ik alleen met HTMLArea, FCKeditor ed heb is de output. De MSHTML output is zachtgezegd ranzig. Is er niet een simpele editor dit ook nog eens xhtml uit kan spugen? now that would be something..

woensdag 30 juli 2003 14:12

Acties: