Hi!

On 9/22/07, Vincent Massol <vincent@massol.net > wrote:

Thinking more about storing documents into a DOM in the database, I
have found 2 issues to discuss:

1) Using verbatim blocks is going to be a nightmare for users.
Consider your example below using verbatim blocks:

-------------------------------------
// WikiModel:
-------------------------------------
<div>
<h1>Hello {{{$customer.Name}}}!</h1>
<table>
{{{#foreach( $mud in $mudsOnSpecial )

    #if ( $customer.hasPurchased($mud) )
}}}
       <tr>
         <td>
{{{         $flogger.getPromo( $mud )
}}}
         </td>
       </tr>
{{{
    #end
#end
}}}
</table>
</div>

It's really ugly and eve worse than the <% from groovy.. :)

I would say that your example should be:
----------------------------------------------------
= Header1 =
This  is a normal wiki syntax...

* list item one
* list item two

And the verbatim block below contains Velocity markup:
{{{
<div>
<h1>Hello {{{$customer.Name}}}!</h1>
<table>
#foreach( $mud in $mudsOnSpecial )
   #if ( $customer.hasPurchased($mud) )

      <tr>
        <td>
          $flogger.getPromo( $mud )

        </td>
      </tr>
   #end
#end
</table>
</div>
}}}

This  is a normal wiki syntax again...
----------------------------------------------------

In this case the processing of your verbatim block will lead to generation of the (X)HTML. (It is up to the template implementor to generate a well-formed XHTML).

By the way: maybe I was not clear but all "<" and ">" symbols in normal wiki blocks (like paragraphs, tables; not in verbatim blocks) are considered as "special" symbols.
For example the "before<table>after" string in the middle of a wiki document will be reported in listeners as following:
- onWord: "before"
- onSpecialSymbol: "<"
- onWord: "table"
- onSpecialSymbol: ">"
- onWord: "after"

 2) We need to consider current users who are using velocity

intermixed with wiki syntax and we need to continue supporting them,
either by having TextProcessors and a VelocityTextProcessor (thus
storing text in the DB) or by somehow converting the current way of
writing velocity to the "new" way, whatever this is. But in any case
we need to find something better than what is in 1) above. I'd hate
that it be worse for users. This leads me to believe we might need to
keep TextProcessors and store the content in textual format in the DB.

You can have the following scenarios:

Scenario A: Processing of the  source for each request
1. You load your content from  the DB
2. You process the content using a template engine (Velocity/Freemarker/StringTemplate/...). The whole page is considered as a simple template for the corresponding template engine.
3. The results of such a processing is parsed by the WikiModel parsers.
pro: You template engine can be used to generate additional wiki elements. No needs to use "embedded blocks" and stuff like that
con: You have to repeat the operations 2) and 3) for *each request*. These steps are the slowest steps in the page processing.

Scenario B: You process only some verbatim blocks containing template-based "inclusions".
1. You load your page from the DB as an XML document or as a wiki syntax
2. You parse it and transform the content into an in-memory structure (DOM). This object can be cached in memory.
3. You handle only some verbatim blocks in this DOM structure to transform its content using a template engine.
pro: For each query you repeat only the step 3. The initial DOM structure is the same and it can be cached. In this case we avoid the parsing the wiki document from wiki syntax or DOM
con: You can not generate the wiki syntax. Your template blocks have to generate the resulting (X)HTML.

Personally I prefer the Scenario B. In this case some verbatim blocks can be considered as an HTML/TeX/... markup, as Groovy/Javascript/JPython/JRuby/... script blocks and some - as template blocks (Velocity/Freemarker/StringTemplate/...)

BTW: I created a very simple common template API which is available in the public Nepomuk repository. There are two implementations for this API: a Velocity and a Freemarker-based on (see Freemarker here: http://freemarker.org/) I think it is easy to implement the same API for StringTemplate (http://www.stringtemplate.org/). It may be useful for the future implementations of the XWiki templating...