Re: [Jamwiki-devel] Custom Tag discussion

[<jam...@li...>]

Hello,

On 1/3/2012 10:21 PM, jam...@li... wrote:
 > I see the Custom Tag initial implementation and realized that this is
 > what I was looking for.

While I have high hopes for the custom tag implementation, it is fairly 
new and not entirely complete, so there are no doubts it needs 
improvement - while trying to add support for an <iframe> custom tag and 
a custom tag to add social media buttons I've hit the same issues you've 
described.

> First of all I don't thing that the name of the tag should be hardcoded
> in the Java. This may cause the name conflict if 2 different custom tag
> classes would use the same name. Instead the name should be configured
> in the jamwiki-configuration.xml file along side with Java class.

This would be an easy change and I can try to get something committed to 
trunk today.

> Second. The parce(...) method converts Wiki text inside custom tag into
> Wiki text to replace that tag. This is obviously useful in some cases
> (like <gallery> tag), but limited. On one hand the replacement is done
> after template substitution, so the replacing Wiki text should be final
> and can not use any shortcuts (like templates). On another hand
> replacing Wiki text with HTML fragment is still subject for Wiki
> configuration and limitations in terms of supported HTML tags.

While I generally like the JFlex lexer, it has made custom tags 
difficult.  Currently the parser does several passes when parsing:

   1. Parse templates.
   2. Parse custom tags.
   3. Parse metadata.
   4. Parse to HTML.
   5. Post process (add TOC, references, etc).

As you've noted, a current limitation of custom tags is that they must 
emit syntax that will not later be escaped by another parsing pass.  The 
parse2HTML(...) solution you've proposed would be a good one, but there 
would need to be a way to specify that a fragment should not be further 
parsed.  I was thinking of something similar, basically:

   * Make step four ("Parse to HTML") aware of custom tags, so that
     rather than escaping them they are treated as valid parser input.
   * This could be done in a few ways, the simplest of which might just
     be to allow custom tags to implement a "no parse" directive that
     works similar to "<nowiki>".  Thus a custom iframe tag might
     generate output similar to "<__NOPARSE><iframe... /></__NOPARSE>"
     to indicate that the content inside of the "__NOPARSE" tags should
     be ignored.  Obviously the "__NOPARSE" tags would need to be
     stripped in step 5, and input would need to be examined in step 1
     to ensure that this functionality was not abused by malicious users.

I think that would meet your needs as well as my own - a custom tag (or 
any other parser code) could explicitly output text that would not be 
parsed further, allowing output as HTML, Javascript, etc.  However, the 
existing parser rules would not be violated.  I may try to put some test 
code together this afternoon to determine if this approach is feasible, 
but please let me know your thoughts as I haven't spent enough time on 
this idea that I'm confident it will meet all requirements.

Ryan