cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <>
Subject HTML editor widget (was Re: [proposal] Doco)
Date Wed, 29 Oct 2003 10:40:09 GMT
On Tue, 2003-10-28 at 19:20, Stefano Mazzocchi wrote:
> > [1] Spoiling Bruno's "lonesome hacking cowboy" thought train, I just 
> > want to confirm that he actually started working on this.
> Yey!!!
> > He's still in a grumpy "friggin' stupid and unstable web browsers and 
> > Javascript as a development hosting environment"

for the record: I've never said any of that.

>  mood, though, so 
> > please light a candle for him. ;-)
> I can do more: I'm willing to help!! Bruno, ask me if you need anything 
> (even privately, if you think it's better)

I've only just started with some little javascript experiments, so it's
not like any code has been written yet.

Here are some first random thoughts:

* different users of the widget (like the doco project vs the project
where we need it) will likely require different subsets of HTML to be

* support for both Mozilla and IE is important. Other browsers should
fall back to a textarea with raw HTML in it.

* the HTML produced by the editor should be cleaned (i.e. not supported
tags & attributes removed) and normalized (formatted). The goal of this
is to deliver a nice XHTML-subset-doc for storage, and to show nice HTML
to people editing it manually. Hopefully this will also make it possible
to do meaningful text-based diffs.

My first thought was to do this cleanup stuff serverside (could be as
simple as an XSL, which would make it easily customisable too). However
it seems like you want to do all that on the client side?

* Currently in e.g. Linotype the source for the editor (thus of the
iframe) is fetched separately from the main page. This is harder to do
with cforms since then the pipeline from which the content is fetched
should also have access to the cforms Form which is stored somewhere in
a variable in a flowscript. For the cforms widget it would be easier I
think to embed the HTML directly in the page (e.g. as a Javascript
variable). This also makes it possible to assign the content either to
the html editor or the textarea depending on what the client supports.

* Automatic image upload: still need to think more about this. After
pressing the submit button (and afterwards possibly showing the form
again), the images will need to become available in the URL space. How
that's done will probably differ from application to application so we
could put that behaviour behind an interface.

* wiki syntax support: we have no need for this, so don't expect any
effort from me on that.

Bruno Dumon                   
Outerthought - Open Source, Java & XML Competence Support Center                

View raw message