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
|