On Sept 11, 2002 [xfer] suggested:

;:''How about a text rewrite plugin, to change all ":)" to a graphical smile?''

What I have wanted is a plugin that would be able to read in the whole page and act as a filter for the page.  And changing :) to a graphical smile is not what I needed, but it could do the trick.

--[NiiloNeuvo]

Another usefull thing would be the rewriting of TeX sequences like \omega ⇒ ω.

--[m0gg]

Yes, they might be useful.  They could also be used to "pluginize" the current TranslatorReader interface.

How about the following Java interface?

{{{
public interface PageFilter
{
/** Called before TranslatorReader starts translating. */
public String preTranslate( String pageContent );

/** Called after TranslatorReader has finished. */
public String postTranslate( String pageContent );
}
}}}

Hm.  The ordering of the different PageFilters might be problematic.

--[JanneJalkanen]

I agree.  Better to have it be a Reader than to have to pass in a String to manipulate. --[Sam]

In a sense, a global pagefilter (i.e. #1 below) can be thought of as an extension to the wiki formatting.  It would be way cool if the TranslatorReader was pluggable, that way people could extend their own JSPWiki instances with their own (simple) custom formatting rules (like the smiley face), and we avoid bloating/gold-plating the existing JSPWiki source.

Ordering is an issue, but you could simply install filters in your config file as either pre or post translate, and then specify the order of the filters.  -- KenLiu

This may be a seperate issue than a global [PageFilter].  A form of [custom field] like \''fieldname''{''whatever''} could be supported, and then a simple hook facility could be provide to implement the handling of just that field. ''field'' is mapped to the custom handler, and ''whatever'' get's passed to the custom handler, which can then output whatever it wants.  Much easier than implementing a [PageFilter] that has to parse everything looking for some special markup. --[Sam]

I actually implemented what I needed (a templating system for wiki-pages):

{{{
public String execute(WikiContext context, Map params)
... stuff deleted
WikiEngine wiki=context.getEngine();
String pure=wiki.getText(source);
pure=pure.replaceAll(regex,replacement);
return wiki.textToHTML(context,pure);
}}}

--[NiiloNeuvo]

Yes, but you need to define this separately for every page.  Which is not nice.

--[JanneJalkanen]

I think you are talking about two different things, above. Janne's thinking of a
global filter applied every time a WikiPage is read, Niilo about a way of creating
single pages by grabbing a template page and modifying it appropriately on the fly.
The former is useful for JSPWiki as a whole, the latter meets a special need (and is
quite doable as a [plugin|JSPWiki plugin], and probably is not useful as part of the JSPWiki distribution).

--[ebu]

The code above does filtering and works nicely and is not a performance problem (Wiki seldomly is).  It is not intended as a solution for anything, but as an example that is doable.

We just basically seem to have three different needs.
#Filter (set of filters) for all pages
#Filter for an individual page
#Filter that copies material from one page to another (plugin)

--[NiiloNeuvo]

Hi..

The PageFilter would be very useful.How long it would take to implment this feature?

--[Arek]

Depends on which version you mean (see above).  #1 you can do pretty easily yourself (just modify InsertPageTag, for example) for a single-instance solution (though building a more complex solution can be a bit of a problem);  #2 requires all sorts of interesting hacking;  and #3 is very easy to do on your own, as suggested by NiiloNeuvo above.

--[JanneJalkanen]

I would like to have a simple filter that would filter the whole page, for two purposes:
* To highlight Search terms in the search results\\''(see request and element of solution in [SearchEnhancements] : "Highlight the search words in the found pages." --AlainRavet)''
* To add a spell checking facility (my daughters are awful at spelling).
** Starting from something like [this|http://www.broken-notebook.com/spell_checker/index.php] might make your job a lot easier. You would jave to change the PHP code to Java though, but it is not a lot.

Both would mark with class="whatever" the matches of a regexp, and the spell checking page would offer a dialog
box in the bottom to replace, ignore, etc. the marked words.

Far fetched, but it looks possible

--[Santiago Gala]

----

There is now an initial implementation of PageFilters in the current [alpha version|Release2.2Discussion].  Please take a look at it and see if it is of any use to anyone. I am less than happy with its current implementation, but it should work.  For example:

* Passing parameters to the filters is practically impossible right now.  The limitations of the java property files are showing.  I don't like the idea of having a separate config file for filters, either, especially since it would probably have to be XML.
* It is hard to limit the effect of a filter to a subset of pages.  It could probably be done with the new SET directive, though.

I decided to go with String manipulation instead of Readers simply because they are far easier for developers to manage.

-- JanneJalkanen, 01-Jun-2003.

There is a new XML-based system for filter management in 2.1.88.  Please see the documentation provided in the distribution archive.

-- JanneJalkanen, 22-Nov-2003.

----

I like the concept of page filters, but something needs to be done about text within triple braces. Either the filter itself needs to understand that it should not modify text within triple braces, or some parameter should be passed to the filter to let it know that it is evaluating text located within triple braces.

I suppose there could be instances where one would want the text to be interpreted, but wouldn't a statement like double percent "prettify" be more appropriate for that.

\\
--Gerard Perreault, 2011-01-25
----
Other [Category Ideas]