[
https://issues.apache.org/jira/browse/SHINDIG-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Hjelmstad resolved SHINDIG-571.
------------------------------------
Resolution: Fixed
> Create shared intermediary representation of mutable HTML content for Gadget
> and HttpResponse to use.
> -----------------------------------------------------------------------------------------------------
>
> Key: SHINDIG-571
> URL: https://issues.apache.org/jira/browse/SHINDIG-571
> Project: Shindig
> Issue Type: Sub-task
> Components: Common Components (Java)
> Reporter: John Hjelmstad
> Assignee: John Hjelmstad
>
> While it still appears to make sense to have two Content Rewriter APIs, one
> for HTTP responses (makeRequest et al) and one for Gadget rewriting, it
> remains true that most rewriters will treat each relatively the same: obtain
> contents, manipulate, output.
> As much code as possible should be shared for each rewriter API. This is
> facilitated by a shared notion of mutable HTML content - the type that's
> actually rewritten.
> Thus I'd like to create a new class, MutableHtmlContent, which has the
> following methods:
> MutableHtmlContent.setContent(String)
> String MutableHtmlContent.getContent()
> ParsedHtmlNode MutableHtmlContent.getParseTree()
> ...in other words, the content manipulation methods from Gadget pulled out
> into a context-agnostic object that simply maintains a String and its
> parse-tree equivalent.
> This code will be shared between Gadget and HttpResponse. At present, this
> arrangement seems convenient:
> 1. Gadget extends MutableHtmlContent. It could simply contain a
> MutableHtmlContent object as well, but doing so would simply have it passing
> through same-named methods. This can be changed later if conditions dictate.
> 2. Augment HttpResponse with a new method:
> HttpResponse.getMutableHtmlContent(), which returns a MutableHtmlContent if
> the MIME type is appropriate. A "force" option could be provided here as well.
> Given these changes, rewriters can easily be implemented in terms of helper
> methods that consume and manipulate MutableHtmlContent in the majority case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
