| Summary: | Abstracts with more than one <para> fail | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Community] PressGang CCMS | Reporter: | Ruediger Landmann <rlandman> | ||||
| Component: | CCMS-Core | Assignee: | Lee Newson <lnewson> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |||||
| Severity: | urgent | Docs Contact: | |||||
| Priority: | urgent | ||||||
| Version: | 1.1 | CC: | lnewson, mcaspers | ||||
| Target Milestone: | --- | ||||||
| Target Release: | 1.3 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2013-12-03 22:16:23 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Bug Depends On: | |||||||
| Bug Blocks: | 1012194 | ||||||
| Attachments: |
|
||||||
|
Description
Ruediger Landmann
2013-10-02 05:42:23 UTC
I've done a partial implementation on this, however I'd like to brain storm with the team about a better way to display multiple paragraph abstracts in a content spec. With the current implementation the format is: Title = Content Spec Processor Guide Subtitle = Using the Content Spec Processor for Topic-based Authoring Abstract = [<para>A guide to using the Content Spec Processor subsystem of Skyn$ <para>Testing having multiple abstracts.</para>] Product = Engineering Content Services Version = 1 Copyright Holder = Red Hat, Inc So basically whatever is placed between the square braces is placed directly inside the <abstract> block in Book_Info.xml. The content is also validated to make sure it is valid XML as per BZ#1019013. The above would also allow for formalpara and simpara to be used instead of whatever you use just being wrapped in a <para>. After talking to the team, we've decided to store more complex abstracts as a topic as it keeps the Content Spec cleaner and allows for more expansion. To use a topic as the abstract you need to do the following:
Use an abstract with an id, eg:
Abstract = [24991, rev: 400000]
or
Abstract = [N, Abstract]
When creating the topic via the UI, you should make the topic appear as is in Book_Info.xml. eg:
<abstract>
<para>
This is the first paragraph in the abstract.
</para>
<para>
This is the second paragraph in the abstract.
</para>
</abstract>
and then make sure it is tagged with the "Abstract" topic type tag.
When attempting to create a new Abstract with the syntax
Abstract = [N, Abstract]
I get the error:
ERROR: Line 6: Invalid Topic! Writer name doesn't exist.
-> Abstract [N, Abstract]
ERROR: The Content Specification is not valid.
This is actually the expected behaviour, but I'll note it here for clarification. The syntax that should be used when creating a new Abstract topic is:
Abstract = [N, Abstract, writer=mcaspers]
Confirmed that a new topic is created with the syntax: Abstract = [N, Abstract, writer=mcaspers] Created attachment 828452 [details]
Abstract topic
When built with CSProcessor client version: 1.3-SNAPSHOT, Build 201311211312 I get the result in the previously attached screenshot. This is actually a bug in the saving mechanism, as the Content Spec has the following after a new abstract has been created: Abstract = Abstract [43397] Since that isn't the syntax for a Meta Data topic it is reverting back to the normal mechanism which is to assume the input is just plain text. Perhaps the validation should be expanded to see if the abstract matches a regular topics syntax and produce a warning. Fixed in 1.3-SNAPSHOT build 201311251126 The merge mechanism wasn't updating the node type and as such when it was being rendered as text it was reverting to the old mechanism which would display the output as above. Also I'm going to leave this as assigned for now so that I can look into updating the validation to pick up possible invalid topics. Note: The above version is currently live on the development/test server. Since you can't accurately determine if the syntax matches a topic due to the multiple different ways a topic can be defined, I've updated the parser to check if what would be classed as the Topic Title matches the metadata key and if it does it'll remove it and then parse the metadata topic as per normal. |