[
https://issues.apache.org/jira/browse/SHINDIG-571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12628527#action_12628527
]
Kevin Brown commented on SHINDIG-571:
-------------------------------------
It's not HTML content. It's only HTML content a small percentage of the time.
Why can't rewriters just be implemented to take a mutable parse tree and the
appropriate context (i.e. the original objects, probably mapped to a common
interface)?
HttpResponse MUST NOT be made mutable -- including the addition of mutable
fields. This is critical.
We just worked through a whole lot of stuff to make it immutable (again). This
is incredibly important since HttpResponse is the primary object in caches.
Once again, this is cramming behavior into HttpResponse that just doesn't
belong there.
The interface should be changed to just take both the original object and the
mutable thing being operated on. Cramming it into some other object is nothing
but a lot of bugs waiting to happen (i.e. Law of Demeter violation).
> 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.
