[RFC] Integrate s9e\TextFormatter

[CHItA]

Why 3.2 version of parsing is better?
Thanks in advance!

That is just the format that the TextFormatter uses. How one stores data is not really makes anything better or worse, the reason why 3.2's BBCode parsing is better is just simply because the features that comes from the new TextFormatter.

[xiri]

That is just the format that the TextFormatter uses. How one stores data is not really makes anything better or worse, the reason why 3.2's BBCode parsing is better is just simply because the features that comes from the new TextFormatter.

Can I use the old parsing format in some way? Maybe there are some settings?

[JoshyPHP]

No, there's no such setting. Why do you need the old format?

[xiri]

No, there's no such setting. Why do you need the old format?

Thanks for the answer! I am planning to add a forum to a mobile application and will make api. I would like to work with a more familiar format. Now I am considering 3.1 and 3.2 to determine what is best version to use for my purposes.

[3Di]

No, there's no such setting. Why do you need the old format?

Thanks for the answer! I am planning to add a forum to a mobile application and will make api. I would like to work with a more familiar format. Now I am considering 3.1 and 3.2 to determine what is best version to use for my purposes.

This ticket? https://tracker.phpbb.com/browse/PHPBB3-13802
I think is a great idea. Any news?

[rxu]

Having 2 bbcodes - one without and another with the = sign, like that:
[ref]{TEXT}[/ref]
<span style="font-weight: bold;">{TEXT}</span>


[ref={COLOR}]{TEXT}[/ref]

<span style="font-weight: bold; color: {COLOR};">{TEXT}</span>

And the former isn't parsed but the latter is.
Is that intended or a bug?

[JoshyPHP]

Kind of neither. I discovered that phpBB would allow two custom BBCodes of the same name if exactly one of them used a parameter a good 2 years after finishing the implementation. Since then I haven't really seen any real-world example of such a pair of BBCodes. There's a ticket there: https://tracker.phpbb.com/browse/PHPBB3-14357

I wrote a routine to merge those BBCode definitions during loading but I didn't have any real-world data to test it against so it never went anywhere: https://gist.github.com/JoshyPHP/6d9c2f ... d854dcc542

Maybe this could be implemented as a migration so that the new definition appears in the ACP (replacing the two old definitions) instead of being implicitly merged. Would you be interested in taking point on this?

[rxu]

I would, although I have no clue where I could be useful (excepting real bbcode definitions and/or testing).

[JoshyPHP]

You can be useful by handling the PR from start to finish. The best way to handle multiple BBCode definitions with the same name may be to replace them with a definition that covers both use case, and do so as a migration.

So far I've seen two different use cases:

1. The [url] BBCode requires a value for the URL but if the user doesn't give one it uses the content of the BBCode. Either way the template is the same.
2. Your [ref] BBCode accepts an optional parameter and uses a different template whether it is present or not.

In the first case, the original 3.1 BBCodes are something like that:

Code: Select all

[url]{URL}[/url]

Code: Select all

[url={URL}]{TEXT}[/url]

Code: Select all

<a href="{URL}">{TEXT}</a>

The template for 3.2 wouldn't change but the definitions would need to be merged together as such:

Code: Select all

[url={URL;useContent}]{TEXT}[/url]

As I recall, that's what I implemented in the Gist I posted above.

In the second case, both the definitions and templates would need to be merged into something like this:

Code: Select all

[ref={COLOR;optional}]{TEXT}[/ref]

Code: Select all

<xsl:choose>
	<xsl:when test="@*">
		<span style="font-weight: bold; color: {COLOR};">{TEXT}</span>
	</xsl:when>
	<xsl:otherwise>
		<span style="font-weight: bold;">{TEXT}</span>
	</xsl:otherwise>
</xsl:choose>

In the template above, @* is an XPath expression that means "all/any attributes."

[Ger]

I see the optional attribute actually works if I put this in the ACP:
[ref={COLOR;optional;defaultValue=inherit}]{TEXT}[/ref]
It accepts both ways, eg. when I write this:

Code: Select all

[ref]Test without attr[/ref]
plain text
[ref=#FF0000]Test with red color[/ref]

It gets parsed like

Code: Select all

<span style="font-weight: bold; color: inherit;">Test without attr</span><br>
plain text<br>
<span style="font-weight: bold; color: #FF0000;">Test with red color</span><br>

Hence: if no color is given, it uses the default value (in this case: inherit). Of course some conditional statements like de XSL scheme would be more powerful, but I think this would cover most cases where an optional attribute is required.