MobileRead Forums - View Single Post - Custom field 'Plain text, not shown in the tag browser', just like 'Title'

chaley · 07-22-2016, 05:01 AM

In the thread in development forum I suggested using two properties in order to separate the content type from the presentation. One property would control whether the item was labeled or not, and the other would control what is stored in the column. In that thread I suggested using booleans.

This scheme has the advantage that it covers four of the needs that (I think) BetterRed expressed in his posts:

Labeled HTML: usable for short fields that contain links and the like
Unlabeled HTML: what we have today
Labeled plain text: what DaltonST and others want.
Unlabeled plain text: I think that BetterRed is asking for this. Its main use would be long plain-text commentary or formatted data such as json.

However, after thinking BetterRed's comments it occurs to me that the content type should be a string, not a boolean. That would permit future developers to add specialized data. To avoid breaking internal and external clients the rule would be that the data must be stored as text, base64 if the data is binary. Clients would display the base64 data (or nothing) if they are not prepared to handle the content type.

The content types I see as most useful would be html (the default), txt, binary, png, and jpg.

Also potentially useful would be an "owner" property that would indicate what component is permitted to edit the field. This could prevent someone from changing a field in such a way as to break the plugin (or whatever) that depends upon the value. This would be a "social agreement" unlike the editable base custom column property, making it easier to use the data in GUI plugins.

07-22-2016, 05:01 AM	#22
chaley Grand Sorcerer Posts: 12,476 Karma: 8025702 Join Date: Jan 2010 Location: Notts, England Device: Kobo Libra 2	In the thread in development forum I suggested using two properties in order to separate the content type from the presentation. One property would control whether the item was labeled or not, and the other would control what is stored in the column. In that thread I suggested using booleans. This scheme has the advantage that it covers four of the needs that (I think) BetterRed expressed in his posts: Labeled HTML: usable for short fields that contain links and the like Unlabeled HTML: what we have today Labeled plain text: what DaltonST and others want. Unlabeled plain text: I think that BetterRed is asking for this. Its main use would be long plain-text commentary or formatted data such as json. However, after thinking BetterRed's comments it occurs to me that the content type should be a string, not a boolean. That would permit future developers to add specialized data. To avoid breaking internal and external clients the rule would be that the data must be stored as text, base64 if the data is binary. Clients would display the base64 data (or nothing) if they are not prepared to handle the content type. The content types I see as most useful would be html (the default), txt, binary, png, and jpg. Also potentially useful would be an "owner" property that would indicate what component is permitted to edit the field. This could prevent someone from changing a field in such a way as to break the plugin (or whatever) that depends upon the value. This would be a "social agreement" unlike the editable base custom column property, making it easier to use the data in GUI plugins.