Re: [Jamwiki-devel] Custom Tag discussion

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

The following changes have been recently committed:

* Revision 3920 supports configuration of the tag name from the
   jamwiki-configuration.xml file as previously discussed.
* Revision 3923 adds support for <__NOPARSE> as described in the
   previous email.
* Revision 3924 implements extension tags for iframe, Facebook
   "like" buttons, and Twitter "tweet" buttons.

This code is still a work in progress, and not something that I'm 100% 
sure will be the long term solution, but I'm going to try this out on a 
couple of sites I operate to see how things work out.

Feedback would be appreciated.  One enhancement I'd like to make is to 
allow configuration parameters to be passed in when initializing tags so 
that (for example) the Facebook tag could be configured to ignore any 
URL that pointed to an external site, or tags could be marked as valid 
for use on only a specified list of topics.  I'm also not thrilled with 
using jamwiki-configuration.xml to manage this functionality, so that 
may also change in time.

Again, any feedback would be great - let me know if this meets your 
needs, if there is an alternative that you feel would be cleaner, or if 
there are still limitations that require addressing.

Ryan


On 1/4/2012 10:13 AM, Ryan Holliday wrote:
> 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
>