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
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.
