h2g2 The Hitchhiker's Guide to the Galaxy: Earth Edition

What diagnostic tool? It would still be impossible to extract the XML (GuideML) from an HTML page because it would all be offline, so test is unavailable. What a WYSIWYG editor needs to be is an HTML editor which has a test type function to display the XML (GuideML).

Of course if the towers were to do this, they'd be able to have it as a limited set of HTML tags to be uploaded. But a project like this can only have an output of GuideML to be copied and pasted into a new entry.

A WYSIWYG editor for GuideML need not have anything to do with HTML/XHTML/XML per se. It could be entirely self-contained, doing its own drawing for display (eg a Windows program) and having a text file in GuideML as its input and output. However, it could additionally have a GuideML to HTML converter which processes a GuideML file into an HTML file for separate off-line display.

NB You can't really do any of this off-line because of the PICTUREs and SMILEYs - unless you were planning to rip-off the entire BBC database (and re-release it every day with the new ones). There is also the matter of different skins from people's preferences (and the various sites) being incorporated into what you see.

The pictures could just be a common jpg or something which says "(Your picture here)" or something. There's also the issue of copyright for other pictures (like the top banners and things), which can't be distributed in a package like this.

The skins should be reasonably easy once the basic concept is conquered. For example P always goes to another P tag, and GUESTBOOK always contains a form and a few other things. But then you have the tags like header which are totally different between Goo and Brunel, so that becomes complicated.

The suggestion of doing it from scratch using standard drawing tools becomes just as difficult - I tried it briefly a couple of years ago when I first looked into a WYSIWYG editor. The main problem is typing on the page and being certain which element has to contain the text, and the best way I think of doing that is to convert it back from HTML. The only reliable way of doing this seems to be using contenteditable - see the paragraph on my space.

I'd still be interested in the idea from Johann though, if he thinks it's possible I'd like to see it!

"The pictures could just be a common jpg"

Unfortunately size (if not image) matters when considering the flow of the text near it and how things fit on the page.

True, although having something that is approximately the same is better than nothing!

The thing is, i'm looking at this like a visual-oriented XML editor. That's not quite the same thing as a HTML editor, although XHTML editors are a subset of what it is - i'd say the ideal way of doing this would be to define a new setup for handling it, that takes the place of (as the setup is designed to allow) the HTML handler in the Swing API of Java.
And i'm going to guess that as sun is so pro-XML with java, it shouldn't - shouldn't - be too horribly difficult. i'm looking into learning the particulars of the API now.

I'd be very interested to see how this is done. I'm quite technology agnostic, other than I believe we should use something which (a) allows us to accomplish what we want to do quickly and (b) is deployable to the greatest number of potential users. I don't see 'cross-platform' as being a major requirement as the law of diminishing returns might prevail in developing such a product. I'm a MS-based developer and I prefer to use MS tools, simply because it's easiest from my point of view.

One point which is worth examining further is the suggestion that it is possible to write an editor from first principles, managing text layout, screen updates, messages etc. This is *very* difficult. Our approach is to see whether there are any third-party components which do this for you. There is one, which you might have heard of. It's called Internet Explorer . IE is based on a rendering engine called MSHTML, which also supports directing editing within the browser. MSHTML is not easy to program but it does allow some wonderful things to be achieved. So we see it as being much easier to hijack the HTML editing capability of MSHTML to do the donkey work for us.

FM

Diminishing returns on cross-platfrom work isn't so much of a concern with Java, as all the work in making it cross-platform is done by the JRE, which (with JIT compilers, others just translate as they go, which is ineffecient) translates near-machine-code bytecodes to machine code as it loads. I actually probably would end up doing my programming on a Linux server that i'm not even touching on the campus of my school, some of the testing there, and other parts of the testing on my windows box...
There's also the matter of how i can use the existing components to put together a browser/editor for text/rtf/HTML in maybe half an hour. It'll take a bit of work to define a new document model etc. for GuideML, but it's designed to be possible and doable.. and things like screen management, text layout, etc. are done by another component...
Now, whether i can find the time to do it is another matter. *Sigh*.

There is the aspect of returns diminishing through the development process being made more complex: I don't know of any Java-based HTML editing components with the power and flexibility of MSHTML, which makes me think that the rendering will have to be done from scratch. But do feel free to prove me wrong.

How does http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/JEditorPane.html look?

Interesting . Some questions:
* Will it recognise and handle CSS?
* Can you cordon-off various areas of the screen as non-editable?
* What's the Undo support like?

CSS... i'm honestly not sure, and i'm not sure if the CSS support is in the HTML-specific portions or elsewhere...
And looking at the StyleSheet class, it does support CSS, but does not support the full CSS spec. I can't see that being a huge problem, though, it should be sufficient.
In terms of cordoning-off parts of the screen, probably... but why?
and the undo support is quite good, and is implemented by a class that is separate from the Document and EditorKit classes.
the Document class lets you define a document structure, ultimately however you like but it's oriented towards XML/HTML type documents, and the EditorKit is... well, just that. it's a class that knows how to edit a particular sort of Document. and every time there is a change in any of the views of a document, an event is sent through that document to all other views, and an event specifically describing an undoable edit is sent to an undo manager, which will keep a stack of them. Or, ultimately, behave in any way you tell it to, but that's beside the point.

The whole API is fairly intricate, and i don't have too much time to go learn it completely, but it's definitely well-designed and it certainly is designed to be usable for any form of text document. it may even be possible to just subclass the HTMLDocument and HTMLEditorKit classes, add the GuideML tags and make the EditorKit not allow anything we don't want, and then use the rest of the framework that's there for HTML.

Just to give you some idea of how intricate and manipulable the text package is, there are 118 classes and 22 interfaces in the javax.swing.text package and it's subpackages.
And almost all of those are classes that i can subclass and so redefine if i need to. But there also is in this mess a working editor for HTML, and RTF, and plaintext.
The Java people are also mildly psycho about making things as general-purpose as they can.

Go for it! Only, read the GuideDog functional spec first.


FM