Allow for CDATA in description fields

[rock3r]

The RSS and content:encoded tags should change their type from String to some sealed class that can be correctly encoded as raw string, or CDATA entry. If you just set the CDATA in the string, it gets escaped when writing the feed, which is not the intended behavior:

    <description>&lt;![CDATA[ 
        ...
     ]]&gt;</description>

expected:

    <description><![CDATA[ 
        ...
     ]]></description>

[257]

@rock3r, any work being done on this? if not, any pointers as to where to look to start contribution?

[rock3r]

Hi @257 — I haven't worked on this for a while, maybe @mpgirro has plans but I'm not sure.

[257]

i could pick this up if need be. is there any pattern in the code that you would suggest to follow to implement/fix this?

[rock3r]

In general, trying to imitate the code style and patterns already used seems a reasonable idea — but I have kinda forgotten how this all works in the 2+ years since I last wrote a line of code for it I'm afraid, so I can't be more specific :)

[257]

of course, story of my life.
@mpgirro, any help?

[mpgirro]

Hi! I also haven't worked on this for quite a while now unfortunately, so no specific plans on how to approach this at the moment. But I hope to be able to start contributing soon(ish) again.

Any help is welcome. We do have some model classes that support more special requirements on their data values already. Have a look at:

• ItunesCategory
• StyledDuration
• GeographicLocation
• TranscriptType
• MediaType

for examples.

Some general remarks to keep in mind:

• We support parsing and writing equally, so every new namespace added or change needs to support both directions.
• Regarding patterns, we heavily use the builder pattern. One is available for almost every model class, and the model classes provide a factory method for their respective builders in their companion objects. Some classes also provide a factory for their value directly (or even both). You'll see how this is done by studying some companion objects.
• A design goal of this library is to provide an idiomatic Kotlin API while also exposing a Java-friendly API. Have a look at the official Calling Kotlin from Java interoperability page for guidance.

Looking forward to you merge request! :)