You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by "John Hjelmstad (JIRA)" <ji...@apache.org> on 2008/09/03 02:21:44 UTC
[jira] Commented: (SHINDIG-503) Augment Gadget object to maintain
both String and Parse Tree rendering state
[ https://issues.apache.org/jira/browse/SHINDIG-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627863#action_12627863 ]
John Hjelmstad commented on SHINDIG-503:
----------------------------------------
I had in mind for this change to go hand-in-hand with cleanup of the ContentRewriter interface.
After some analysis, it looks like the ContentRewriter interface for now should maintain two interfaces, one for HTTP requests and one for Gadget rewriting.
Kevin's changes to GadgetContext make for a great context object to pass into the Gadget rewriting interface.
The main open question seems to be whether the Gadget object or some modifiable subcomponent of it is passed into the interface. I see both sides of the argument, but at present still lightly favor Gadget itself. Concretely, I'd change the gadget rewriting interface to:
RewriterResults ContentRewriter.rewrite(GadgetContext context, Gadget gadget)
Meanwhile, these changes would accompany:
1. Add a new method, GadgetHtmlNode Gadget.getParseTree().
2. Augment GadgetHtmlNode with an "edit listener" that signals its "host" Gadget object when an edit operation has been done (just a boolean)
3. Gadget.setContent() and GadgetHtmlNode.<editOperation>() disallowed when the other has been called to maintain object consistency.
The overhead with #2-3 is real, but pretty small since it's just checking a shared boolean.
I prefer this approach at present for the following reasons:
1. Allows both String and ParseTree based rewriting (though of course, all PT rewrites should happen together to avoid de/reserialization!)
2. Even if not ideal long-term, serves as a stepping-stone to something like ContentRewriter.rewrite(GadgetContent, GadgetSpec, GadgetHtmlNode) since it punts on the question of turning _all_ content, including JS libraries, into GadgetHtmlNodes. Rewriting happens before other operations, so doing the latter would add complexity I'd like to avoid for the time being.
> Augment Gadget object to maintain both String and Parse Tree rendering state
> ----------------------------------------------------------------------------
>
> Key: SHINDIG-503
> URL: https://issues.apache.org/jira/browse/SHINDIG-503
> Project: Shindig
> Issue Type: Sub-task
> Components: Gadget Rendering Server (Java)
> Reporter: John Hjelmstad
> Assignee: John Hjelmstad
>
> Point #4 of http://mail-archives.apache.org/mod_mbox/incubator-shindig-dev/200808.mbox/%3cab5e78ed0808061534r48c04de5j8909bc7e8316cc22@mail.gmail.com%3e
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.