[
https://issues.apache.org/jira/browse/WAVE-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13028825#comment-13028825
]
Michael MacFadden commented on WAVE-263:
----------------------------------------
One place this code is used is in the WaveletBasedConversationBlip class. This
class implements the ConversationBlip interface. This interface defines the
following three methods:
Iterable<? extends ConversationThread> getReplyThreads();
Iterable<? extends ObservableConversationThread> getAllReplyThreads();
Iterable<? extends InlineReplyThread<? extends ObservableConversationThread>>
getInlineReplyThreads();
currently get getReplyThreads() returns threads where
ConversationThread.isInline() is false, and getInlineReplyThreads() returns
threads where ConversationThread.isInline() is true. If we are removing the
logic around isInline() it seems like these methods are also now irrelevant. I
would create a separate issue to remove these methods after this task is done.
However, the question is how should these behave right now. I see a few
options.
1) All three return all threads.
2) getReplyThreads() returns ALL threads, getInlineReplyThreads() returns NO
threads.
3) getReplyThreads() returns NO threads, getInlineReplyThreads() returns ALL
threads.
Thoughts?
> ConversationThread.isInline is still used in some parts of the codebase
> -----------------------------------------------------------------------
>
> Key: WAVE-263
> URL: https://issues.apache.org/jira/browse/WAVE-263
> Project: Wave
> Issue Type: Bug
> Reporter: David Hearnden
> Assignee: Michael MacFadden
> Priority: Minor
>
> In Google Wave, there were four types of reply threads:
> inline=false, no content anchor => an indented reply thread outside the
> parent blip.
> inline=false, with content anchor => corrupt data, but treated anyway as
> above
> inline=true, no content anchor => unanchored inline reply, rendered at the
> end of the parent blip (inside).
> inline=true, with content anchor => anchored inline reply, rendered at the
> content anchor (inside).
> In Undercurrent / WIAB, this distinction based on the inline attribute in the
> manifest is no longer made. Reply threads are just reply threads. Any reply
> thread can have an anchor in its parent blip's content, and if there is such
> an anchor, the thread is rendered there, otherwise it is rendered at the end
> of the parent blip's content. The rendering and behaviour of the two cases
> is identical (unlike Google Wave). The only difference is the location where
> the thread is rendered. Essentially, this means that "indented"
> replies, as opposed to "inline" replies, are gone.
> All code that is causing divergent behaviour based on
> ConversationThread.isInline() needs to be fixed. In most cases, the
> expression:
> ConversationThread.isInline()
> can be replaced with:
> true
> followed by consequent refactoring and dead-code removal etc.
> ---
> Issue imported from
> http://code.google.com/p/wave-protocol/issues/detail?id=264
> Owner: [email protected]
> Cc: [email protected]
> Cc: vega113
> Label: Type-Defect
> Label: Priority-Medium
> Stars: 1
> State: open
> Status: New
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
