uPortal IRC Logs-2008-01-18

Owned by Apereo Infrastructure
Last updated: Jan 18, 2008Version comment
13 min read

[00:50:41 EST(-0500)] * deuce_ (n=deuce@ip68-3-31-85.ph.ph.cox.net) has joined ##uportal
[08:59:35 EST(-0500)] * esm (n=esm@asdf.dkc.jhu.edu) has joined ##uportal
[09:48:30 EST(-0500)] * clown (n=clown@142.150.154.101) has joined ##uportal
[10:39:28 EST(-0500)] * EricDalquist (n=EricDalq@76.201.146.71) has joined ##uportal
[11:01:05 EST(-0500)] * esm (n=esm@asdf.dkc.jhu.edu) has joined ##uportal
[11:03:05 EST(-0500)] * esm (n=esm@asdf.dkc.jhu.edu) has joined ##uportal
[11:42:29 EST(-0500)] * athena7 (n=athena7@lumina.its.yale.edu) has joined ##uportal
[11:46:11 EST(-0500)] <EricDalquist> hey deuce, are you on uportal-dev?
[12:21:52 EST(-0500)] * deuce_ (n=deuce@uni1.unicon.net) has joined ##uportal
[12:36:15 EST(-0500)] * pberry (n=pberry@waldorf.CSUChico.EDU) has joined ##uportal
[12:36:22 EST(-0500)] * pberry (n=pberry@waldorf.CSUChico.EDU) has left ##uportal
[12:57:41 EST(-0500)] <deuce_> Eric?
[12:57:48 EST(-0500)] <EricDalquist> hey
[12:58:07 EST(-0500)] <deuce_> hey i was trying to verify the dynamic portlet titles yesterday
[12:58:35 EST(-0500)] <deuce_> and it seems to only work for the first setTitle
[12:58:51 EST(-0500)] <EricDalquist> hrm, yeah I haven't gotten to fully testing it
[12:59:01 EST(-0500)] <EricDalquist> so that doesn't surprise me too much
[12:59:09 EST(-0500)] <EricDalquist> I'm assuming it is because the chrome is cached?
[12:59:38 EST(-0500)] <deuce_> i think the problem is that in UserInstance, the title is part of the system caches .. which are only tied to those system cache keys
[13:00:22 EST(-0500)] <deuce_> right .. the chrome is cached separately than the content
[13:02:14 EST(-0500)] <deuce_> there are a few approaches that will solve this. in the mood to discuss them?
[13:02:17 EST(-0500)] <EricDalquist> does ChannelManager.getChannelTitle() get called on every rener though? (sorry I'm still not all that familiar with uPortal's caching functionality)
[13:02:19 EST(-0500)] <EricDalquist> sure
[13:02:36 EST(-0500)] <EricDalquist> I need to figure more of this stuff out for the theme changes Gary is working on anyways
[13:03:19 EST(-0500)] <deuce_> well, the user instance object employs two types of caches: system and channel content
[13:03:49 EST(-0500)] <deuce_> the channel content caches cache just that .. the result of the renderXml or renderCharacters
[13:04:33 EST(-0500)] <deuce_> everything else on the page is chunked up as page fragments and this includes the channel chrome
[13:05:52 EST(-0500)] <EricDalquist> so the channel content cache looks like it lives as a member of ChannelManager: Map<IChannel, Map<String, ChannelCacheEntry>> channelCacheTable right?
[13:06:27 EST(-0500)] <deuce_> ChannelManager.getChannelTitle() will get called on the occurrence of the end </channel> tag during the theme transform
[13:06:42 EST(-0500)] <deuce_> correct
[13:07:03 EST(-0500)] <EricDalquist> and the system caches (caching page fragments) are Map<String, SAX2BufferImpl> systemCache and Map<String, CharacterCacheEntry> systemCharacterCache
[13:07:18 EST(-0500)] <EricDalquist> which are in StaticRenderingPipeline (what used to be the logic bits of UserInstance)
[13:09:17 EST(-0500)] <EricDalquist> (sorry for all the questions, I just want to make sure I'm in the right place)
[13:09:32 EST(-0500)] <deuce_> Ok.. I haven't looked at the up3 refactoring of the rendering pipeline. But it seems to be consistent from up26
[13:09:40 EST(-0500)] <deuce_> no problem
[13:11:02 EST(-0500)] <deuce_> yeah StaticRenderingPipeline looks very much like UserInstance
[13:11:47 EST(-0500)] <EricDalquist> yeah, all I did was make it a singleton and UserInstance is now simply a data object
[13:12:13 EST(-0500)] <deuce_> ok
[13:13:12 EST(-0500)] <deuce_> so two things came to mind for solutions
[13:13:12 EST(-0500)] <EricDalquist> so .. we have these caches ... getChannelTitle gets called once per channel per theme transform
[13:13:28 EST(-0500)] <deuce_> correct
[13:13:55 EST(-0500)] <EricDalquist> I'm guess the problem is that 'channel-title' element is only looked at if the theme fragment cache is invalid
[13:14:19 EST(-0500)] <deuce_> yup
[13:14:44 EST(-0500)] <deuce_> which means that all channels have the same constraint on the validity of their chrome
[13:14:55 EST(-0500)] <deuce_> on the same page that is
[13:16:07 EST(-0500)] <EricDalquist> ah, so one channel changes title, we have to re-do the entire cached theme transform?
[13:16:31 EST(-0500)] <deuce_> in our current caching approach, yes
[13:17:14 EST(-0500)] * esm (n=esm@asdf.dkc.jhu.edu) has joined ##uportal
[13:24:26 EST(-0500)] <EricDalquist> so ... ideas for fixing it (now that I understand what is going on, thanks (smile) )
[13:26:40 EST(-0500)] <deuce_> so one thing .. is we could extend the theme data model to have <channel/> contain a child element for the channel content
[13:27:12 EST(-0500)] <deuce_> so the <channel/> would be tied to the chrome
[13:27:31 EST(-0500)] <deuce_> and <channel-content/> would be the .. content
[13:28:20 EST(-0500)] <deuce_> and both would be tied to the channel's isCacheValid (or we could make it selective)
[13:29:00 EST(-0500)] <deuce_> but then this moves the rendering of the channel's chrome into a separate process (transformation)
[13:29:10 EST(-0500)] <deuce_> but these are very lightweight
[13:29:57 EST(-0500)] <deuce_> so that's the more complex option
[13:30:21 EST(-0500)] <deuce_> alternatively, we could make the channel's title an ajax element
[13:31:23 EST(-0500)] <deuce_> i haven't thought through the details of how the dispatching would work, but it shouldn't be too bad
[13:31:33 EST(-0500)] <EricDalquist> could we do something like #1 that but give the chrome its own cache key generation? So if isCacheValid is false we then check if any of the <channel> attributes that contribute to the chrome have changed and re-render the chrome then?
[13:31:48 EST(-0500)] <EricDalquist> then on most renders the chrome could still be cached ...
[13:32:35 EST(-0500)] <deuce_> yeah that's the more selective route
[13:33:11 EST(-0500)] <EricDalquist> hrm, on first impression #1 sounds like a better long term solution, the ajax idea might be nice but adds more complexity into the theme itself which may not really be needed
[13:33:38 EST(-0500)] <deuce_> i agree with that
[13:34:07 EST(-0500)] <EricDalquist> could you give me a slightly more detailed look into what would be involved with moving the chrome for each channel into its own rendering fragment with corresponding cache key?
[13:34:28 EST(-0500)] <EricDalquist> do we go all out and do <channel><chrome/><content/></channel> in our extension
[13:34:45 EST(-0500)] <EricDalquist> so there is the ability to add more dynamic data in the chrome at a later date?
[13:34:53 EST(-0500)] <deuce_> I think just <channel><content/></channel> is sufficient
[13:34:56 EST(-0500)] <deuce_> ah
[13:34:57 EST(-0500)] <deuce_> maybe
[13:35:44 EST(-0500)] <deuce_> then the xsl that performs the chrome, will need to be broken out into its own stylesheet
[13:35:59 EST(-0500)] <EricDalquist> right now I can't think of other things but I could see that being useful in the future for other pseudo channel controled chrome content
[13:36:11 EST(-0500)] <deuce_> right
[13:36:46 EST(-0500)] <deuce_> then we'd have two placeholders in the sax stream, one for the chrome and one for the content
[13:36:57 EST(-0500)] <EricDalquist> right
[13:37:03 EST(-0500)] <deuce_> actually the one for the chrome would produce the one for the content
[13:37:17 EST(-0500)] <EricDalquist> yeah
[13:37:18 EST(-0500)] <EricDalquist> well
[13:37:28 EST(-0500)] <EricDalquist> I was thinking you start channel rendering on <channel>
[13:37:34 EST(-0500)] <deuce_> yes
[13:37:55 EST(-0500)] <deuce_> oh you put chrome and content at the same level
[13:37:56 EST(-0500)] <deuce_> hmm
[13:38:27 EST(-0500)] <deuce_> i don't think that gives the ability to provide chrome after the content
[13:38:40 EST(-0500)] <deuce_> i.e. end tags
[13:38:43 EST(-0500)] <EricDalquist> ah
[13:38:47 EST(-0500)] <EricDalquist> good point
[13:39:21 EST(-0500)] <EricDalquist> so <channel><channel-content/></channel> makes sense as you just treat <channel> as the chrome
[13:39:35 EST(-0500)] <deuce_> right
[13:39:59 EST(-0500)] <EricDalquist> the only issue then is if you ever want to get stuff into the title that won't validly live in a XML attribute
[13:40:00 EST(-0500)] <deuce_> but we could have <channel><chrome><content/></chrome></channel>
[13:40:10 EST(-0500)] <EricDalquist> right?
[13:41:06 EST(-0500)] <deuce_> why wouldn't it?
[13:41:25 EST(-0500)] <EricDalquist> good point
[13:42:02 EST(-0500)] <deuce_> we're changing it so that we can detect when it changes and update as necessary
[13:42:08 EST(-0500)] <EricDalquist> yup
[13:42:21 EST(-0500)] <EricDalquist> so the additional XSL
[13:42:46 EST(-0500)] <EricDalquist> we're talking another transform step? or just additional features in the existing theme XSL?
[13:43:27 EST(-0500)] <deuce_> it would have to be additional xsl to be able to reproduce it when only the chrome attributes change
[13:43:34 EST(-0500)] <EricDalquist> ah yeah
[13:43:48 EST(-0500)] <deuce_> it's actually another N steps
[13:43:49 EST(-0500)] <EricDalquist> so it would be a parallel (out of band?) XSL transformation step
[13:43:52 EST(-0500)] <EricDalquist> yup
[13:43:53 EST(-0500)] <deuce_> but small ones
[13:44:11 EST(-0500)] <EricDalquist> so we would be adding a bit of complexity to the theme XSL authors
[13:44:22 EST(-0500)] <deuce_> since they're placeholders, they could be paralleled.
[13:44:28 EST(-0500)] <EricDalquist> saying that you do the whole theme as one XSL ... except for the channel chrome which is all by itself
[13:45:02 EST(-0500)] <deuce_> well the complexity right now is n
[13:45:18 EST(-0500)] <deuce_> with this it will be 2n -> n
[13:46:01 EST(-0500)] <EricDalquist> yup
[13:46:17 EST(-0500)] <EricDalquist> so one question that I think we should look at is
[13:46:45 EST(-0500)] <EricDalquist> what is the probable cost of just tying the theme transform cache key to the channel titles
[13:46:56 EST(-0500)] <EricDalquist> so if a channel title changes we re-do the whole theme transform
[13:46:58 EST(-0500)] <EricDalquist> oh
[13:46:59 EST(-0500)] <EricDalquist> nevermine
[13:47:01 EST(-0500)] <EricDalquist> thats too late
[13:47:24 EST(-0500)] <EricDalquist> we don't know about the title change until after the theme transform load from cache/re-render decision has been made
[13:47:35 EST(-0500)] <deuce_> nah you could check if they change prior to hitting the rendering pipeline
[13:47:50 EST(-0500)] <deuce_> well..
[13:47:51 EST(-0500)] <EricDalquist> but you need to render all the channels to do that
[13:48:20 EST(-0500)] <EricDalquist> since they don't tell you until after they complete rendering
[13:48:24 EST(-0500)] <deuce_> you wouldn't i don't think. we'd have access to all their channel manager. we'd just ask them
[13:49:47 EST(-0500)] <deuce_> you would have to parse the layout though to identify which channels
[13:49:54 EST(-0500)] <EricDalquist> ChannelManager.getChannelTitle looks in the channel rendering table for the last IChannelRenderer result
[13:50:41 EST(-0500)] <EricDalquist> so if during a request if a channel changes its title it won't be available via ChannelManager until after the rendering is complete and the channelRenderer table is updated
[13:51:07 EST(-0500)] <deuce_> ah yes
[13:51:24 EST(-0500)] <deuce_> right because it's state could change during rendering
[13:51:27 EST(-0500)] <EricDalquist> yup
[13:51:35 EST(-0500)] <EricDalquist> otherwise we would always be 1 request behind
[13:51:39 EST(-0500)] <deuce_> right
[13:51:48 EST(-0500)] <EricDalquist> friggin portlets
[13:52:00 EST(-0500)] <EricDalquist> response.setTitle should really be a callback instead
[13:52:16 EST(-0500)] <EricDalquist> oh well
[13:52:45 EST(-0500)] <EricDalquist> so, we're stuck with not rendering the chrome for a channel until after the channel rendering is complete
[13:54:14 EST(-0500)] <EricDalquist> or starting the N channel renderings and waiting for them to complete before starting the theme transform
[13:54:47 EST(-0500)] <deuce_> yes it would have to wait for the renderings to complete
[13:54:58 EST(-0500)] <deuce_> hmm. i think that just complicated matters
[13:55:23 EST(-0500)] <EricDalquist> which overall wouldn't change render times but it sure would change the user experience and yes, complicate things
[13:56:19 EST(-0500)] <deuce_> all this for a seemingly simple feature
[13:56:27 EST(-0500)] <EricDalquist> yup
[13:56:35 EST(-0500)] * EricDalquist shakes fist
[13:56:59 EST(-0500)] <EricDalquist> your ajax idea is sounding better and better (tongue)
[13:57:02 EST(-0500)] <EricDalquist> so ...
[13:57:04 EST(-0500)] <deuce_> haha
[13:57:04 EST(-0500)] <EricDalquist> another option
[13:57:08 EST(-0500)] <EricDalquist> or idea
[13:57:33 EST(-0500)] <EricDalquist> add a channel title cache (just cache the strings)
[13:57:48 EST(-0500)] <EricDalquist> and in the chrome cached with the theme just put a placeholder
[13:57:55 EST(-0500)] <EricDalquist> similar to the channel placeholder used now
[13:58:36 EST(-0500)] <deuce_> hmmm
[13:58:58 EST(-0500)] <EricDalquist> and the channel incorporation filter replaces the <channel-title/> placeholder at the same time it is replacing the <channel/> placeholder
[13:59:06 EST(-0500)] <EricDalquist> since it already has to wait for each channel to finish
[13:59:14 EST(-0500)] <EricDalquist> that wouldn't shake up the rendering pipe
[13:59:20 EST(-0500)] <EricDalquist> wouldn't cause theme re-renders
[13:59:27 EST(-0500)] <deuce_> no it wouldn't
[13:59:30 EST(-0500)] <EricDalquist> wouldn't split up the theme XSL
[13:59:33 EST(-0500)] <deuce_> nope
[13:59:35 EST(-0500)] <EricDalquist> would add another cache
[13:59:39 EST(-0500)] <EricDalquist> but thats ok
[13:59:43 EST(-0500)] <deuce_> it's looking better
[14:00:10 EST(-0500)] <EricDalquist> is it the CharacterCachingChannelIncorporationFilter that does the channel replacement right now?
[14:00:17 EST(-0500)] <deuce_> yeah
[14:00:57 EST(-0500)] <deuce_> i think there are two, one for the full rendering .. and one for only channels
[14:01:13 EST(-0500)] <EricDalquist> ok
[14:01:36 EST(-0500)] <EricDalquist> so then we just need to tweak the theme xsl to write out a special element where the channel title should go
[14:01:45 EST(-0500)] <deuce_> yes
[14:01:53 EST(-0500)] <EricDalquist> we may have to put a bit of thought into that to allow some flexibility for the theme designer
[14:02:08 EST(-0500)] <EricDalquist> like allow something similar to the <xsl:attribute> tag
[14:02:15 EST(-0500)] <EricDalquist> so they can use the title in alt text and stuff
[14:02:37 EST(-0500)] <EricDalquist> I see why peter was going in the direction of custom xml processing namespaces in the sandbox
[14:05:41 EST(-0500)] <deuce_> focused channels use it as the title of the page
[14:06:20 EST(-0500)] <deuce_> or they could.. it think they use the @name attribute currently
[14:06:34 EST(-0500)] <EricDalquist> yeah
[14:06:46 EST(-0500)] <deuce_> wait isn't that the title
[14:06:53 EST(-0500)] <EricDalquist> yeah
[14:06:57 EST(-0500)] <deuce_> hehe
[14:07:15 EST(-0500)] <EricDalquist> so that adds a bit of complexity into the filter
[14:08:04 EST(-0500)] <EricDalquist> since for each <element> we would have to see if the first child is <up:chanTitleAttr name="alt"/> before passing along <element> in the filter chain
[14:10:31 EST(-0500)] <deuce_> Why would a parent's element need to be filtered? Just the <up:chanTitleAttr name="alt"/> piece needs to get processed differently.
[14:11:14 EST(-0500)] <EricDalquist> so say the theme wants the channel's title as alt text for an image: <img alt="channelTitle" src="foo.jpg" />
[14:11:48 EST(-0500)] <EricDalquist> the theme can't really write out <img alt="<channel-title/>" src="foo.jpg" /> since that isn't valid XML (or can it?)
[14:12:09 EST(-0500)] <deuce_> it could if we had <up:img/> tags
[14:12:36 EST(-0500)] <EricDalquist> we would need something like that for every case of using the channel title as an attribute
[14:14:07 EST(-0500)] <deuce_> hmm i just thought of something
[14:14:35 EST(-0500)] <deuce_> those channel placeholders are only produced on a full page rendering
[14:15:14 EST(-0500)] <deuce_> on subsequent renderings, when only the channel content is processed, it doesn't follow that sax filtering
[14:15:40 EST(-0500)] <EricDalquist> how does the channel content get pushed in?
[14:16:39 EST(-0500)] <deuce_> it loops through those system character caches
[14:16:53 EST(-0500)] <EricDalquist> ah
[14:17:10 EST(-0500)] <EricDalquist> and in between each 'chunk of characters' writes out the channel
[14:17:15 EST(-0500)] <deuce_> and alternates between feeding the response with systemCache and systemCharacterCache content
[14:17:42 EST(-0500)] <deuce_> foobar
[14:17:51 EST(-0500)] <EricDalquist> so we would have to chunk up the content even more, separating it around each need for a channel title
[14:18:39 EST(-0500)] <deuce_> right it would have to alternate between systemCache chromCache contentCache endChrome systemCache chromeCache ...
[14:19:27 EST(-0500)] <deuce_> that was the implied approach for option #1
[14:19:42 EST(-0500)] <EricDalquist> and actually more complex than that since we have use cases for channel titles in places other than just the channel chrome
[14:20:01 EST(-0500)] <deuce_> where else?
[14:20:17 EST(-0500)] <deuce_> oh page title
[14:20:31 EST(-0500)] <deuce_> and in the header
[14:20:41 EST(-0500)] <deuce_> for focused channels
[14:20:45 EST(-0500)] <EricDalquist> yup
[14:20:58 EST(-0500)] <deuce_> well that's stinky
[14:21:21 EST(-0500)] <EricDalquist> I need to go look in the rendering code at how those caches are used when just re-rendering channels
[14:21:25 EST(-0500)] <EricDalquist> see if I get any ideas
[14:21:31 EST(-0500)] <deuce_> please do
[14:21:47 EST(-0500)] <EricDalquist> let me finish writting up a Jira for Drew and I'll go dig a bit
[14:21:55 EST(-0500)] <EricDalquist> are you going to be around for a little bit?
[14:22:08 EST(-0500)] <deuce_> okie dokie.. i have to go running, but I'll be back in about an hour
[14:23:03 EST(-0500)] <EricDalquist> sounds good
[14:23:08 EST(-0500)] <deuce_> have to go .. sounds like a chore
[14:23:30 EST(-0500)] <deuce_> alright, i'll touch base when I get back
[14:23:41 EST(-0500)] <EricDalquist> (smile) later
[14:23:45 EST(-0500)] <deuce_> peace
[14:31:47 EST(-0500)] * clown_ (n=clown@142.150.154.101) has joined ##uportal
[15:37:10 EST(-0500)] * deuce_ (n=deuce@uni1.unicon.net) has joined ##uportal
[15:41:53 EST(-0500)] * awills (n=awills@12.164.136.183) has joined ##uportal
[15:42:28 EST(-0500)] <awills> esm are you there? I have a small m2 question for you
[15:42:47 EST(-0500)] <esm> awills: hey
[15:42:55 EST(-0500)] <esm> is there such a thing as a small m2 question ? (smile)
[15:43:02 EST(-0500)] <EricDalquist> lol
[15:43:11 EST(-0500)] <esm> whew
[15:43:14 EST(-0500)] <esm> eric is here too
[15:43:23 EST(-0500)] <EricDalquist> for about 15 minutes
[15:43:31 EST(-0500)] <esm> oh
[15:43:46 EST(-0500)] <awills> that's a quandry in itself
[15:43:51 EST(-0500)] <esm> in that case you can answer xtra small m2 questions
[15:44:22 EST(-0500)] <awills> here's the deal... all the poms have SNAPSHOT in them for the <version>, and i want to build an M5
[15:44:52 EST(-0500)] <awills> is there a better way than simply hand-editing all the pom.xml files to say <version>M5</version>
[15:45:04 EST(-0500)] <EricDalquist> mvn release plugin!
[15:45:07 EST(-0500)] <esm> yyes
[15:45:08 EST(-0500)] <esm> !!!!
[15:45:10 EST(-0500)] <awills> is there some automated means to build a particular named version?
[15:45:11 EST(-0500)] <esm> mvn release
[15:45:14 EST(-0500)] <EricDalquist> yay I knew something!
[15:45:26 EST(-0500)] <esm> EricDalquist: oh man, please at this stage....
[15:45:28 EST(-0500)] <awills> neat, how does it work? (smile)
[15:45:36 EST(-0500)] <esm> mvn release:prepare
[15:45:38 EST(-0500)] <esm> mvn release:perform
[15:45:59 EST(-0500)] <awills> wow, and you can do that w/o changing any XML? (wink)
[15:45:59 EST(-0500)] <EricDalquist> yeah the release plugin will update your poms, commit the change, deploy the artifact change the poms to the next version, commit that change
[15:46:07 EST(-0500)] <esm> yah
[15:46:09 EST(-0500)] <EricDalquist> with 2 command lines and some prompts
[15:46:12 EST(-0500)] <esm> it xforms the pom
[15:46:17 EST(-0500)] <esm> for you
[15:46:24 EST(-0500)] <EricDalquist> http://maven.apache.org/plugins/maven-release-plugin/
[15:46:47 EST(-0500)] <EricDalquist> hey deuce
[15:50:12 EST(-0500)] <deuce_> hey
[15:50:23 EST(-0500)] <EricDalquist> so I have to run out for a bit in about 5 minutes
[15:50:43 EST(-0500)] <deuce_> ok.. i'm going to explore some then
[15:50:46 EST(-0500)] <EricDalquist> but I looked at the rendering code (I really want to re-write that)
[15:50:52 EST(-0500)] <deuce_> oh?
[15:51:03 EST(-0500)] <EricDalquist> just break it up so it is easier to parse
[15:51:10 EST(-0500)] <EricDalquist> so I'm not sure what the best course is going to be here
[15:51:20 EST(-0500)] <deuce_> omg .. that's needed refractoring for a long time now
[15:51:25 EST(-0500)] <EricDalquist> yeah
[15:51:37 EST(-0500)] <EricDalquist> unless channel titles cause it that probably won't happen for 3.0
[15:51:44 EST(-0500)] <EricDalquist> but I can see that happening in a 3.1 or so
[15:51:59 EST(-0500)] <EricDalquist> so back to channel titles ... if we only had to worry about channel titles as elements in the chrome this would be a bit simplier
[15:52:03 EST(-0500)] <deuce_> yeah it probably won't be necessary
[15:52:18 EST(-0500)] <EricDalquist> (man ... sorry for the spelling today)
[15:52:28 EST(-0500)] <deuce_> no problem
[15:52:29 EST(-0500)] <deuce_> (smile)
[15:52:33 EST(-0500)] <EricDalquist> but the idea that channel titles can be used elsewhere in the markup make this more difficult
[15:53:10 EST(-0500)] <deuce_> well what about well defined tokens in attributes.. the filters could definitely pick up on that
[15:53:14 EST(-0500)] <awills> esm it's asking me "What is SCM release tag or label..." can i put an SVN URL in there you think?
[15:53:26 EST(-0500)] <EricDalquist> I believe what peter had done for the sandbox code was a slightly more complex cache than the current CharacterCacheEntry
[15:53:33 EST(-0500)] <esm> you just put in a single word or name that the tag should be
[15:53:36 EST(-0500)] <esm> IIRC
[15:53:38 EST(-0500)] <esm> so like
[15:53:45 EST(-0500)] <esm> pluto-1.1.5
[15:53:50 EST(-0500)] <esm> or foo-ver3
[15:54:04 EST(-0500)] <awills> i don't think the poms know anything about where branches go
[15:54:06 EST(-0500)] <esm> that names the directory under http://your/svn/server/tags/
[15:54:10 EST(-0500)] <EricDalquist> so instead of two List<String> that are interleaved we had a List<cached object type> that had some 'greater meaning'
[15:54:11 EST(-0500)] <esm> ah
[15:54:22 EST(-0500)] <esm> wellyou have to have the <scm> element in the pom i believe
[15:54:32 EST(-0500)] <EricDalquist> so in the code that runs on a character cached entry would iterate through this list
[15:54:32 EST(-0500)] <awills> you think it would guess to put it in tags/?
[15:54:41 EST(-0500)] <EricDalquist> some items would be theme characters
[15:54:45 EST(-0500)] <awills> i do have the <scm>
[15:54:52 EST(-0500)] <EricDalquist> some would be ChannelTitleMarkers with a channel id attribute
[15:55:05 EST(-0500)] <EricDalquist> and some would be ChannelContentMarkers with a chanell id attribute
[15:55:24 EST(-0500)] <esm> awills: cool i think u should be good then
[15:55:27 EST(-0500)] <EricDalquist> the CharacterCachingChannelIncorporationFilter would build this list when it handles a real rendering
[15:55:41 EST(-0500)] <EricDalquist> by looking for <channel-title> elements in the theme generated markup
[15:55:58 EST(-0500)] <deuce_> would you be able to put the markers into an attribute tho?
[15:57:04 EST(-0500)] <EricDalquist> well we would likely still need to do something like <up:chanTitleAttr attrName="alt" chanId="1"/> as a child for a <img> element
[15:57:20 EST(-0500)] <esm> awills: u can also do the dry run: http://maven.apache.org/plugins/maven-release-plugin/usage.html
[15:57:30 EST(-0500)] <EricDalquist> and the incorperation filter would then just need to break up the cache blocks in the List correctly
[15:57:35 EST(-0500)] <EricDalquist> I have to run
[15:57:52 EST(-0500)] <deuce_> ok .. we'll pick this up later. will you be back today?
[15:57:53 EST(-0500)] <EricDalquist> but I'll see if I can sketch out a concept in an email to uportal-dev (do you lurk there?)
[15:57:56 EST(-0500)] <EricDalquist> I will
[15:57:59 EST(-0500)] <EricDalquist> but it may not be for a few hours
[15:58:05 EST(-0500)] <deuce_> i lurk
[15:58:08 EST(-0500)] <EricDalquist> (smile)
[15:58:14 EST(-0500)] <EricDalquist> I'll catch you on IRC or email later
[15:58:17 EST(-0500)] <EricDalquist> have a good one
[15:58:17 EST(-0500)] <deuce_> sounds good
[15:58:20 EST(-0500)] <deuce_> later
[17:34:50 EST(-0500)] * clown_ (n=clown@142.150.154.101) has left ##uportal
[18:07:54 EST(-0500)] * esm (n=esm@207-53-193-105.dynamic-dsl.qis.net) has joined ##uportal
[18:37:55 EST(-0500)] * awills (n=awills@12.164.136.183) has left ##uportal
[18:56:17 EST(-0500)] * athena7 (n=athena7@c-24-2-189-230.hsd1.ct.comcast.net) has joined ##uportal
[20:11:09 EST(-0500)] * deuce (n=deuce@ip68-3-31-85.ph.ph.cox.net) has joined ##uportal
[21:46:01 EST(-0500)] * deuce (n=deuce@ip68-3-31-85.ph.ph.cox.net) has joined ##uportal