Hi Dan, It's really great to see several of you knowledgeable Googlers showing interest!
On Thu, Apr 28, 2011 at 6:54 AM, Daniel Danilatos <[email protected]> wrote: > Hi Thomas, > > As Pat said, it's great to hear you've decided the editor is a good > fit for your project. I'd love to work with you in making the editor > more standalone. If you are OK with it, could you send out a more > detailed proposal of the use cases you need from the editor; then we > could directly help you quickly identify the parts of the code that > would need improvement in order to achieve your goals as soon as > possible. What's in our specs (that our client said they want): - a rich text editor with both "graphical", "structural" and "semantic" markup (see below). - the documents have to be stored in (or easily converted to) XML with strict schemas (looks a bit like DocBook); we actually don't have any constraint re. the storage format - text will have to be spell-checked, but we can very well turn into a specific mode for that where editing would be turned of (like GMail, or the spell check wizard in MSWord/LibreOffice Writer). Particularly, we don't need real-time spellchecking, we can very well send the whole doc to the server, get errors back, and process them. Similarly, we'll do some basic "grammar checking" (correct usage of spaces around punctuation, sentences start with upper-case letter; that's it.) - "graphical" markup includes: bold, italic, underline and line-through (yes, they consider this graphical, not semantic, even though in other discussions they said that if something is bold, it's for a reason, so they nevertheless attach some kind meaning to "something being bold") - "structural" markup includes: - paragraph, heading (levels 1-5) and unordered list (with nesting; lack of ordered list might be an oversight) - tables: with caption, add/remove column/row, merge/split cells - notes (I don't have any more details for now, I don't know if they want "foot notes" –or HTML's <span title="">– or rather a "decorated paragraph" –or group of paragraphs–) - links - images (with caption; à la HTML5's <figure>); these are linked to "illustration" domain objects (including the caption). In the text, the user can define the size of the thumbnail, how text flows around the figure (float), and change the caption's text (could be done in, say, a popup, not necessarily by directly editing the text displayed in the editor) - "semantic" markup is - mostly about attaching a domain-specific term/category to the selected text, e.g. this is a person, date, building material, etc. (there are something like 50 thesaurus/list-of-values to choose from; the user "attaches" the selected text to one such thesaurus, and can optionally select a specific value from the list) I don't know if annotations would be the best fit here: we don't have the constraint of running through several paragraphs, but it's likely that, despite not spec'd, such semantic markup shouldn't overlap; so elements could be used; plus, the value being optional could make it impractical to distinguish "start of annotation without value" from "end of annotation" (if we use the DocInitialization XML representation). - there are also 10 cases where the annotation isn't linked to any thesaurus (e.g. marking up a birth date, a person's given name, a book's publish date, etc.), in this case, we could have a single "kind" with 10 possible values (i.e. kind="birthdate"). Aside of the editor will be outlines: - headings hierarchy - tables - figures - "semantic" markup (grouped by category/type) I was thinking about periodically (every 5secs or so) scanning the document to extract those information along with their location (instead of trying to keep everything up-to-date at each modification) When an item is clicked, the caret should be moved at said location and then scrolled into view if needed. This editor will be used in a dozen places (fyi, we have something like 100 different "forms"), with different features: - "graphical" markup is always "on" (I thought there was one case where it didn't, but re-reading our specs, it seems I was wrong) - "structural" markup can be disabled (i.e. a single line/paragraph; looks like the LinoTextEventHandler could help here), partially enabled (paragraphs, headings and figures only; no text-align, list, table or link; there's also one case where there are only paragraphs and headings) or fully enabled (in a couple places only) - "semantic" markup is always on, but the set of thesaurus/LoVs to choose from is different each time. There are two cases where the edited document can (theoretically) be very large ("up to 80 pages"), and obviously these are the cases where all the features are enabled: think domain-specific Google Docs! I thought about Wave's editor because it is "schema-based" and because of the "structural markup" constraints, particularly when pasting things coming from, e.g. MSWord (something that's likely to be common in our case). We specifically don't need OT or collaborative editing, "just" a rich-text editor with the special features described above. To limit the amount of work, I though about using the Wave's way of marking up <line/>s, at least at the beginning; but maybe it'd be easy to use a more HTML-like <p>...</p> and <h1>...</h1> kind of markup? (and keeping <?a ?> annotations for styling) At first sight, it looks like the Editor is quite tightly bound to <line/>s, but maybe it's just me? If you could give me hints about how best to: - initialize an Editor (use an "owned" ContentDocument or not? what should I register in the registries?) - put content into, and get content out of the editor: should I rather use the "persistent document" (and if yes, which class: PersistentContentDoc, ContentRawDocument? I must confess I'm lost with all these classes and interfaces) or a "doc initialization"? - make my own schema(s), and how to map the "structural" and "semantic" markup (elements? annotations?) It'd help me start customizing the editor to my needs and see what could be improved to make it a standalone component (starting with writing some docs! ;-) ) Thanks (a lot!) in advance. -- Thomas Broyer /tɔ.ma.bʁwa.je/
