[jira] Resolved: (SHINDIG-571) Create shared intermediary representation of mutable HTML content for Gadget and HttpResponse to use.

["John Hjelmstad (JIRA)" <ji...@apache.org>]

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