Yes, I'd like to split up the WikiML generation from the HTML rendering of WikiML, if possible, but they are fairly intertwined at the moment; In most cases a template is retrieved by each handler, rendered, and then the remaining variables (specific to the task at hand) are substituted before printing to STDIO.

I had to do this to prevent some variables from being expanded at the wrong times in the preference editor and other forms. You could say that each handler works pretty much the same as do the current CGI scripts, and is able to handle redirections, printing of pages, etc, on its own.

It'd be nicer if the handler simply returned some WikiML or fully rendered HTML for the MegaCgiScript to print to STDIO.

This brings up another topic: PluginVariableNameClashes.

-- PeterNixon - 14 Jul 2002

Hmm. I think we need to look very closely at why the handlers can't just return WikiML. Not least because invocation through any non-HTML method demands WikiML as the return type.

If anyone has any insights into why they are currently so tied up with each other, please share them. I am particularly interested in what, if anything, we would lose by decoupling them.

I suspect that it might be related to this pair of TWikiDotPm functions but my cursory investigations into exactly what these do have left me more confused than comfortable.

    $text = handleCommonTags( $text, $topic, $web );
    $text = getRenderedVersion( $text, $web );

Perhaps someone can comment on or refer me to documentation explaining the purpose of these two?

-- MartinCleaver - 15 Jul 2002

• handleCommonTags does a single pass of variable substitution for all variables in $text, including variables handled by plugins.
• getRenderedVersion converts WikiML (bullets, tables, headers, bold, italics, etc.) to HTML.

They may actually be a bit more blurred where the SpreadSheetPlugin and similar plugins are concerned, but I haven't read their code yet.

I'm not sure I buy the value of separating out rendering from the handlers, because they are currently doing what was asked of them; Handling an activity, which includes generating pages and printing them to STDIO (this includes generating context sensitive menus, etc). They also call a generic subroutine for rendering WikiML: TWiki::getRenderedVersion. The call to this subroutine could be substituted with another object method which 'knows' which rendering handler to call based on what's requested (XML, HTML, text, etc).

I don't think we'd lose anything, technically speaking, by decoupling WikiML generation inside the handlers from the rendering process. I think the reason for the current setup is that it's easier to code that way for some people, and there didn't seem to be anything wrong with that method at the time (e.g. "follow the leader" coding).

On a lower level note, in order to ensure that variables used by the handlers are not accidentally subsituted by a plugin or other common tags handler, we would have to separate the name space of variables which are subsituted by bin scripts from variables which are substituted by a call to handleCommonTags. A lot of bin scripts would also have to be re-written to be able to simply return WikiML for rendering and printing.

I agree this issue needs discussion, but it's bound to open a can of works with regard to current code; Are we looking at this specifically for TWikiOO, or an intermediate release? It seems to me this should be part of the TWikiObjectResponsibilities discussion after we have had the TWikiOOUseCases and TWikiObjectInteractions discussions (these will be iterative discussions). I don't think it'd be economical (time spent, etc) to implement this with the current code.

I think what you're proposing will occur naturally as a result of a good TWikiOO design.

-- PeterNixon - 15 Jul 2002

CategoryStale