Sure, you can just provide a different DocumentSchema. You'll have to register renderers and event handlers for the various types of elements you plan to support. The reason we use <line> tags is so that the operational transform behavior gives a slick collaborative editing experience. And, also, so we don't have to worry about what it means to edit HTML with random position absolute divs etc as part of the editable content - though you said you have a strict XML schema.
The editor itself is basically an event router. The model is arbitrary, and semantic. All the functionality, from paragraphs, bullets, headings, to gadgets, image thumbnails, spell annotations, and so forth is defined as a set of renderers and event handlers that you register against different element and annotation types. So you could have, e.g., a <my-widget> element with its own schema defining its state, and render that to arbitrarily complex HTML. The purpose of our editor is to give you great control and flexibility over your model, and confidence that your HTML rendering won't turn into a mangled mess as often happens with vanilla HTML text editors. If you want to inter-operate with wave, you must use our schema. Though we plan on fixing this, so people will be able to define their own. If you're just using the editor, you can go ahead and define whatever schema and rendering behaviors you wish. As part of open sourcing, we've also released a bunch of basic behaviors which you can find inside the editor.content package. For example, the editor.content.paragraph package contains the logic for rendering self-closing <line/> tags, with content following, to regular <p> tags in the html with contained content. I'm skipping over a bunch of details, but the rough flow is like this: * LineContainerParagraphiser (great name I know) converts <line> elements into local <l:p> elements within the model (the document supports "local" nodes that are not represented by operations. This is similar to the shadow dom used by browsers like webkit to render widgets from simple html). This is an intermediate step, purely for convenience. * ParagraphRenderer renders the <l:p> elements in the model to <p> elements in the HTML * LocalParagraphEventHandler handles behavior like what happens when the user presses enter. In that example, it would create a <line/> element at the given location, which would then be rendered accordingly. For a much simpler example, see ImgDoodad which basically defines a very html-like <img> element. We used to use regular <p> elements in our model as well. If you want to do this (say if your model is more HTML-like), then you could use ParagraphRenderer or something very similar to it, and the unused class ParagraphEventHandler which is a remnant from our old ways of doing things. It throws UnsupportedOperationException in some places where you'd need to fill in the gaps, but you get the idea. Unfortunately the only documentation of how renderers and event handlers work is in the code. We should fix this. I hope the above is helpful as a starting point regardless. Dan On Jun 10, 12:44 am, Jason Terk <[email protected]> wrote: > Dan, > > Thanks for your response, it was most certainly helpful. One thing, however, > isn't yet clear for me: is there a way to use a different schema for the > editor? It looks to me like the editor expects documents using the <line/> > tag for line separators and outputs the same. I need to be able to process > arbitrary HTML - the editable content is not necessarily coming from my > application's editor (although it does conform to a strict XML schema, if > that helps). > > Thanks again, > -Jason Terk -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
