[
https://issues.apache.org/jira/browse/SHINDIG-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Hjelmstad updated SHINDIG-500:
-----------------------------------
Attachment: shindig-500.diff
Updated patch attached.
This patch cleans up rewriting logic considerably by removing the separated
notion of RewrittenContent and simply treating the Gadget object's Content as
current. Previously, odd logic paths existed such as the fact that Substitution
was required for rewriting to work, as the View.substitute() method used its
own rewrittenContent field to replace its own content.
I've discovered one noteworthy property of this change, however - GadgetSpecs
are cached in *non-rewritten* form by BasicGadgetSpecFactory. This is endemic
to moving the notion of rewritten content out of View and into Gadget.
Is it OK to accept this for the time being? Rewriting, where it applies, will
occur more often during rendering, making it both more dynamic but also more
costly CPU-wise. Since gadgets still need to opt in to rewriting, I'm thinking
the hit will be small compared to the benefits, both short and longer-term.
This topic raises the questions of what purpose GadgetSpecFactory performs, and
whether or not GadgetSpecs should be treated as immutable "seeds" for Gadget
processing or as pre-processed Gadgets themselves (essentially codifying
rewriting semantics ie. that rewritten content is as cacheable as the retrieved
spec itself).
For its part, BasicGadgetSpecFactory adds two concepts atop "fetching a gadget
spec":
A. An LruCache for retrieved GadgetSpecs.
B. Retrieval of type=html href=<foo> View content.
Arguably, both (A) and (B) should be performed higher in the gadget processing
stack, in GadgetServer. Doing so allows GadgetServer to make more nuanced
decisions as to what caching characteristics apply to content and at what
levels, and opens up the opportunity to inject a Gadget cache (probably keyed
on Gadget+"view name") rather than piggybacking on one built into the
GadgetSpecFactory of choice.
Ideally, I'd like to move ahead with this change independent of
GadgetSpecFactory refactoring, particularly since that's more intrusive to the
way a Gadget Server is built. Thoughts?
> Make Gadget Object's content that of the active View
> ----------------------------------------------------
>
> Key: SHINDIG-500
> URL: https://issues.apache.org/jira/browse/SHINDIG-500
> Project: Shindig
> Issue Type: Sub-task
> Components: Gadget Rendering Server (Java)
> Reporter: John Hjelmstad
> Assignee: John Hjelmstad
> Attachments: shindig-500.diff
>
>
> Step #1 of
> http://mail-archives.apache.org/mod_mbox/incubator-shindig-dev/200808.mbox/[EMAIL
> PROTECTED]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
