Re: [Jamwiki-devel] Custom Tag discussion

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

Thanks for the feedback.  Regarding the enhancements, there are some 
limitations imposed by JFlex, most notably that patterns must be known 
at compile time rather than run time.  It's for this reason that custom 
tags must be HTML-like (the JFlex parser can then look for an HTML tag 
pattern), and also why the </__NOPARSE> tag pattern was hard-coded (Note 
that </__NOPARSE> can only be used internally - if an end-user tried to 
include that pattern in a wiki topic it would be parsed just like any 
other invalid HTML).

Regarding your comment about adding four custom tag methods for use of 
custom tags during different iterations of the parser, it's definitely 
something that's doable, but in order to avoid a severe performance 
penalty the implementation would require modifying the code that 
currently handles HTML tags in the jamwiki-processor parser to check for 
custom tags.  Unfortunately that's a big change that I'd be 
uncomfortable including in JAMWiki 1.2 (which is nearly at the end of 
its development cycle), so it would need to be considered for JAMWiki 1.3.

And note that custom tags can already access metadata, topic name, etc 
via the lexer.getParserInput() and lexer.getParserOutput() methods of 
the lexer object that is passed to the tag during parsing.

Let me know if you'd like write access to Subversion in order to be able 
to create your own development branch as it's often easier to have these 
discussions when there is code to discuss.  Alternately, I'll be 
interested to see any tags that are developed when you are ready to 
release them.

Cheers,

Ryan


On 1/19/2012 10:26 PM, jam...@li... wrote:
> Wow! How quick!
>
> Your correct the implementation you explained would allow me to do
> what I am thinking now to do. However there are a few enhancements,
> which I think would make this feature even more flexible and
> powerful:
>
> I don't know JFlex enough to say if this would be too complex, but if
> you can make it aware of Custom Tags on all iterations and call
> different methods for each iteration, then Custom Tag class could
> include in the output the same (or different) Custom Tag to be
> handled by later iterations. If the whole conversion get completed in
> the early iterations, then the class won't insert its Custom Tag and
> later iterations won't even call the methods. In order to do that all
> methods should receive the tag name as a parameter in addition to the
> attributes and inner-text.
>
> In addition the special methods of all Custom Tag classes should be
> called before start parsing the topic and different ones after
> finishing.
>
> All this would allow implementation using Custom Tag functionality
> like TOC or references.
>
> Also would be nice to allow Custom Tag class methods to be able to
> access the environment like Name of the Page, User, created the
> topic, when it was created, same for last update, may be whole
> history, etc.
>
> Because of what I suggested the Custom Tag class would need to
> implement many methods (at least 4) the based class would be helpful
> with default implementations. Before First and After Last methods
> wouldn't have attributes or text to convert and default
> implementation would be empty. The parse to HTML method would copy
> the text into its output, but the rest of the methods would take
> attributes, text and tag name and return the text, surrounded in the
> tag with attributes.
>
> In the mean time I am working on a couple Custom Tag classes of my
> own, which I think would be helpful.
>
>
>
> CAB