I'm thinking that it would be best to store pages in plain html, then use
the HtmlParser to generate the Swiki format when rendering a non-WYSIWYG
edit page. Saving the page could use the existing formatters to render it
into HTML for storage.
Now, the only thing I can think of that you lose in that scenario are the
*pagename* style references that render as a link, with the current page
name as the text in the link. I tried to come up with a way of directly
embedding text from another URL into a page (kind of like embedding
images...which would enable you to pull the name of a page for embedding as
the text of the href), but I didn't find a clean way to do it.
So, now I'm thinking that an HTML friendly way of embedding special content
in a Swiki page might be best for storing...formatting (i.e. bullet lists,
headings, etc) would happen on save, and special Swiki stuff like page refs
would get converted into an HTML friendly storage format.
This leads me to the design of JSP and ASP, etc...which embed server code
using <% and %> tags. Page references could be stored using servlet tags
like:
<%= book pageReference: 1 %>
...other special (non formatting) content could be handled in this way.
Now, this presents another problem...performance. Executing smalltalk code
stored externally in a file requires invocation of the parser and compiler.
For Swiki.net, I have goals to keep page viewing at <50ms of server
processing time...I'll allow a bit more for page editing. So, I think I
could still use Smalltalk syntax, but rather than actually execute it, just
allow a few pre-defined things...until we can pre-compile the stored pages.
- Stephen
> On Tue, 13 Jun 2000, Stephen Pair wrote:
>
> > Has anyone played around with converting plain HTML pages into the Swiki
> > syntax?
>
> Yes, at least, in thought :). Well, there was some dorking around at one
> point...
>
> My prefered idea was to use the HtmlParser to parse the HTML, and then
> either add a "asSwikiFormat" like method to each node, or figure out a way
> that HtmlFormatter could be subclassed to handle it (this was a *while*
> ago!).
>
> The tricky bit, I think, will be preserving markup for which there is no
> direct Swiki equivalent. Of course, you can just pass on those tags, but
> the HTML should be "roundtrippable" to use DreamWeaverSpeak ;)
>
> Indeed, I've thought it would be interesting to parse to a neutral format,
> accepting and providing different edit syntaxes. The main problem, of
> course, is losing stuff in the downtranslation.
>
> But for one time convertions, or learning, this isn't a big deal.
>
> The more general case requires dealing with carefully selected compatible
> subsets of some of the formats, or enduring the painof mixed syntax
> (aieee!) ;)
>
> Cheers,
> Bijan.
>
