Bug 812704 - RFE: Support for entities in Content Specs / Topics
RFE: Support for entities in Content Specs / Topics
Status: CLOSED CURRENTRELEASE
Product: PressGang CCMS
Classification: Community
Component: Web-UI (Show other bugs)
1.x
Unspecified Unspecified
low Severity low
: ---
: ---
Assigned To: Matthew Casperson
:
: 827767 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-15 22:33 EDT by Joshua Wulf
Modified: 2014-10-19 19:00 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-01-13 01:19:28 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Joshua Wulf 2012-04-15 22:33:17 EDT
If you take a look at http://skynet.usersys.redhat.com:8080/TopicIndex/TopicEdit.seam?topicTopicId=7677

the topic is completely reusable except for one thing: the specific content spec ID.

One way around this is to write: "insert the appropriate Content Spec ID", and have a reference topic before the task topic, called "The Content Spec ID of this Book".

Another way to do it would be to insert a Docbook entity like this:

csprocessor checkout &CSPROCESSORID;

and in the Content Spec do this:

  Get the Very Latest Version of This Guide [7677, &CSPROCESSORID=7210]

The builder would then substitute the entity into the topic as it was building the book.

To enable reuse of the same entity across a book, there could be an entities section at the top of the Content Spec, to enable them to be defined globally for the Content Spec.

They would be localised (when appropriate) in the same way that Chapter and Section titles are localised.
Comment 1 Joshua Wulf 2012-04-15 22:34:07 EDT
An unresolved issue with this proposal is how entities are specified / stored / localised for non-Content Spec processor builds of topics.
Comment 2 Joshua Wulf 2012-04-15 22:35:41 EDT
Perhaps Skynet could present a report: 

Here are all the entities that need to be defined for the topics that you've selected for the build.
Comment 3 Joshua Wulf 2012-04-15 22:37:45 EDT
Actually, the Content Spec ID of the current Content Spec being built could be a reflexive. Since the builder knows what it is building, it could be a system-supplied entity.

So on encountering an entity:

&CONTENTSPECID;

The Content Spec processor could automatically replace the entity with the Content Spec ID of the Content Spec being built.
Comment 4 Joshua Wulf 2012-04-15 22:39:39 EDT
Then topic 7210 would be cut-and-paste reusable for all internal documentation initially, and then everything out in Fedora Land as well.
Comment 5 Lee Newson 2012-04-15 22:43:34 EDT
As with Bug #809334 any injection related data must be handled by both Skynet
and the CSP. So moving it to the correct queue and i'll look at the rest of the
content later.
Comment 6 Lee Newson 2012-07-24 18:19:06 EDT
*** Bug 827767 has been marked as a duplicate of this bug. ***
Comment 7 Lee Newson 2012-07-31 23:45:41 EDT
Extra note:

Misty brought up that adding XML Entities brings up issues with translations.
Comment 8 David Ryan 2013-05-13 23:14:25 EDT
I believe Josh is referring only to entities in terms of content spec IDs, not for content in the copy itself. We don't do the latter for reasons you've already touched on in Comment 7.
Comment 9 Lee Newson 2013-05-13 23:37:10 EDT
Yes that is his direct use case, but the RFE never mentions only using it for that. I also can't see an entity just for injecting a PressGang ID to have much use outside of this use case. Also from my perspective, it would be weird to allow some entities and not others (we can only allow entities that won't affect translations).

To do the latter, it would require a fair bit of research and even then I suspect it would be very hard to come up with a rule that would work in all cases.
Comment 10 Lee Newson 2014-01-13 01:19:28 EST
This can be done using BZ#1013882 so marking it as CLOSED.

Note You need to log in before you can comment on or make changes to this bug.