Actually yes. Guest will have access across sessions for sure as well
as users that use the template user's layout (i think). I was going
to suggest just passing in the ChannelManager to replayCache, but yeah
I think passing in UserInstance gives more flexibility for future
mods.
-nick
On Jan 21, 2008 4:53 PM, Eric Dalquist <[EMAIL PROTECTED]> wrote:
>
> Sounds good.
>
> So we would have constructors that look like:
>
> class ChannelTitleCacheEntry {
> private final ChannelManager cm;
> public ChannelTitleCacheEntry(ChannelManager cm) {
> this.cm = cm;
> }
> }
>
> Is there potential for the CacheEntry objects ever to used by more than one
> user? If so that won't work and we would have to use some sort of
> ThreadLocal to provide the ChannelManager (and other classes) to the
> CacheEntry objects which isn't as neat but would work. Another option would
> be to provide all of the user specific rendering pipeline objects to the
> CacheEntry.replayCache method.
>
> Perhaps a method signature of CacheEntry.replayCache(UserInstance ui,
> CachingSerializer cs); since that would give the CacheEntry references to
> all user specific objects it may need during cache replay.
>
> -Eric
>
>
>
>
>
>
>
> Nick Bolton wrote:
> What if we move the replaying semanics to the CacheEntry objects?
>
> So the interface CacheEntry would have an added method,
> interface CacheEntry {
> CacheType getCacheType();
> void replayCache(CachingSerializer cs);
> }
>
> Then each CacheEntry object would do the appropriate action.
>
> StringCacheEntry:
> public void replayCache(CachingSerializer serializer) {
> serializer.printRawCharacters(characters);
> }
>
> ChannelContentCacheEntry:
> public void replayCache(CachingSerializer serializer) {
> getChannelManager().outputChannel(getChannelId(), serializer);
> }
>
> ChannelTitleCacheEntry:
> public void replayCache(CachingSerializer serializer) {
> serializer.printRawCharacters(
> getChannelManager().getChannelTitle(getChannelId()));
> }
>
> The CacheEntry objects would need to have reference to the
> ChannelManager and the CachingSerializer/BaseMarkupSerializer would
> need to extend/implement from a common interface. No big deal.
>
> I think this will clean up the rendering code quite a bit too.
>
> -nick
>
>
> On Jan 20, 2008 9:37 PM, Eric Dalquist <[EMAIL PROTECTED]> wrote:
>
>
> This email is continuing a conversation Nick and I had on the ##uportal
> IRC channel on Friday:
> http://www.ja-sig.org/wiki/display/UPC/uPortal+IRC+Logs-2008-01-18
>
> Looking at the current dynamic title code there are already a few
> restrictions, mainly the title can't be use in an attribute of any
> element in the rendered markup because the
> CharacterCachingChannelIncorporationFilter currently just replaces the
> <channel-title defaultValue="foo" channelSubscribeId="id"/> element with
> the correct title after the theme transform is complete. If this
> restriction is OK than a solution to rendering dynamic titles with
> character caching enabled shouldn't be too difficult to implement as
> follows.
>
> The CharacterCacheEntry class would be changed from a List<String> of
> serialized content fragments and a List<String> of channel ids which are
> interleaved into just a List<CacheEntry> (the CacheEntry class and
> related classes are outlined below). The each CacheEntry would describe
> what content should go in its place, cached serialized characters, a
> channel title, or channel content. For the channel title and content
> entries the CacheEntry would provide the channel subscribe id to get the
> content for. For the cached characters entry the serialized String would
> be part of the entry. The rendering pipeline code that replays the
> cached List<CacheEntry> would then just take the appropriate action
> based on the type of entry and either write out cached data or query the
> channel manager for the channel content or title.
>
> enum CacheType {
> CHARACTERS;
> CHANNEL_TITLE;
> CHANNEL_CONTENT;
> }
> interface CacheEntry {
> CacheType getCacheType();
> }
> class StringCacheEntry implements CacheEntry {
> CacheType getCacheType() {
> return CacheType.CHARACTERS;
> }
>
> String getCachedCharacters(){
> return chars;
> }
> }
> abstract class BaseChannelCacheEntry implements CacheEntry {
> String getChannelId(){
> return id;
> }
> }
> class ChannelContentCacheEntry extends BaseChannelCacheEntry {
> CacheType getCacheType() {
> return CacheType.CHANNEL_CONTENT;
> }
> }
> class ChannelTitleCacheEntry extends BaseChannelCacheEntry {
> CacheType getCacheType() {
> return CacheType.CHANNEL_TITLE;
> }
> String getDefaultTitle() {
> return defaultTitle;
> }
> }
>
>
> --------------------------------------------------------------------------------
> Another (more complex but feature complete) option:
>
> Before looking at the existing code I was trying to think of a way to
> get dynamic titles working in a way that would allow use in XML
> attributes. and here is what I came up with. This approach would require
> a change to existing theme transforms to work. Though I don't think
> anyone really uses dynamic titles yet so that shouldn't be too big of a
> deal.
>
> In the CharacterCachingChannelIncorporationFilter when the
> <channel-title> element is seen instead of writing out the actual
> channel title a big random string is written out. Instead of the filter
> using "private final List<String> systemCCacheBlocks;" to cache the
> character content it uses a more complex object like the one outlined
> below. The object would hold the String character block and a Map of the
> random numbers to channel ids generated for the <channel-title> entries
> in that block. During a replay from cache each block can have the random
> string placeholders replaced with the appropriate channel titles using
> the Map to lookup each string and channel id using String.replaceAll.
> During a full rendering I'm still not sure how to have both the random
> strings written into the character cache and the real titles written out.
>
> class CharacterCacheEntry {
> String characterBlock;
> Map<String, String> channelTitleMarkers;
> }
>
> Another option here which would likely be less performant (though how
> much I don't know) would be to always have a string replacing filter
> wrapping the response PrintWriter and instead of tracking random strings
> to channel ids per block to do it for the entire rendering. The
> replacing filter would then do a String.replaceAll for each random
> string to replace it with the real title. This is probably easier to
> implement and much of the performance issue could likely be mitigated by
> changing how dynamic channel titles work by requiring an IChannel that
> wants to use dynamic titles to implement a specific interface. This
> would allow the CharacterCachingChannelIncorporationFilter to only
> insert random marker strings for these channels and not every channel on
> the page.
>
> I believe the sandbox code has something similar to this approach in it
> though I can't remember exactly what it is for.
>
>
>
>
>
>
>
--
You are currently subscribed to [email protected] as: [EMAIL
PROTECTED]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
