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 [EMAIL PROTECTED] [EMAIL PROTECTED]
