cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <br...@outerthought.org>
Subject Re: HTML editor widget (was Re: [proposal] Doco)
Date Thu, 30 Oct 2003 12:59:46 GMT
On Thu, 2003-10-30 at 10:34, Stefano Mazzocchi wrote: 
> On Wednesday, Oct 29, 2003, at 11:40 Europe/Rome, Bruno Dumon wrote:
> 
> > I've only just started with some little javascript experiments, so it's
> > not like any code has been written yet.
> 
> ok, but it's great to see you doing this
> 
> > 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
> > used.
> 
> True, even if, for XHTML, you can support different modules. For 
> example, I didn't support tables in Linotype.
> 
> > * support for both Mozilla and IE is important. Other browsers should
> > fall back to a textarea with raw HTML in it.
> 
> yes
> 
> > * 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.
> 
> Yep
> 
> > 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?
> 
> Linotype already includes a DOM serializer, I think it already does 
> some pretty formatting and already has the ability to distinguish 
> between whitespace-safe elements and non.
> 
> > * 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.
> 
> I thought about that too: my solution would be to have woody draw the 
> widget as an empty <iframe> and then fill it up at page load time from 
> some client-side javascript.
> 
> In theory it's easy, in practice, I expect tons of bugs and 
> incompatibilities between browsers (but haven't tried yet)

I think it's feasible.

I found this thing called "htmlArea", which is some javascript that
exploits the html editors in both IE and Mozilla, and it does things
like that without trouble.

See here:
http://www.interactivetools.com/products/htmlarea/
and here for an online demo:
http://dynarch.com/mishoo/htmlarea.epl

I'm wondering if maybe we should start from that one (it's BSD-style
licensed).

> Another thing I wanted to try is to embed the icons right into the page 
> instead of having them fetched from outside, this makes is easier since 
> you don't have to mount your icons somewhere in your URI space.
> 
> > * 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.
> 
> hmmm, what aobut giving back the uploaded "Parts" back into the object 
> model that is accessible to the flowscript. the flow will handle them 
> and put them in the proper place... at this point, the flow will have 
> to be able to call a "link translation" on the page.

something like that, yes. I'll come back to this after I've been able to
put some thought to it.

> > * wiki syntax support: we have no need for this, so don't expect any
> > effort from me on that.
> 
> Fair enough, but please keep in mind that the editor will have "multi 
> views" and need to be defined in the description of the widget for that 
> particular form.

ok.


-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org


Mime
View raw message