[07:06:44 CDT(-0500)] <EricDalquist> Arvids: just added you to the uportal dev grou
[07:06:46 CDT(-0500)] <EricDalquist> group
[07:06:52 CDT(-0500)] <EricDalquist> you should now have commit access in svn
[07:07:04 CDT(-0500)] <Arvids> nice
[07:07:05 CDT(-0500)] <EricDalquist> and more permissions in the uportal project on jira
[07:08:39 CDT(-0500)] <EricDalquist> if you want to take a shot at https://issues.jasig.org/browse/UP-3096 for your first change set that would be great 
[07:08:51 CDT(-0500)] <Arvids> i could do so
[07:09:11 CDT(-0500)] <Arvids> i also commented on https://issues.jasig.org/browse/UP-3095 with possible tab name translation possibilities
[07:09:42 CDT(-0500)] <Arvids> and composite message source proposed by you seems the best one
[07:09:51 CDT(-0500)] <EricDalquist> oh great, I'll take a look at that
[07:09:52 CDT(-0500)] <EricDalquist> yeah
[07:09:59 CDT(-0500)] <EricDalquist> that code is really not nice 
[07:12:26 CDT(-0500)] <Arvids> and i've also done some work in order to improve translations
[07:12:46 CDT(-0500)] <Arvids> but i had a problem with parametrizable messages
[07:13:25 CDT(-0500)] <Arvids> i couldn't find a way to use those messages in XSL
[07:17:07 CDT(-0500)] <EricDalquist> hrm, that would be a question for athena
[07:17:18 CDT(-0500)] <EricDalquist> she did the initial work on getting the messages usable in XSL
[07:17:40 CDT(-0500)] <Arvids> ahh... ok
[07:18:12 CDT(-0500)] <Arvids> it would be nice to use them in the same way as they can be used in JSP
[07:18:15 CDT(-0500)] <EricDalquist> there are a set of classes XalanHelper* that are the java callback used by the XSL
[07:18:35 CDT(-0500)] <Arvids> yes, i saw them and tried to tweak them a little
[07:19:22 CDT(-0500)] <Arvids> but I'm not very familiar with XSL and couln't find a way how to pass an object array as argument
[07:19:31 CDT(-0500)] <EricDalquist> you could potentially just add another method: public static String getMessage(String code, String language, String params)
[07:19:36 CDT(-0500)] <EricDalquist> I doubt you can
[07:19:46 CDT(-0500)] <EricDalquist> the JSP taglib already just does string splitting
[07:20:40 CDT(-0500)] <Arvids> hmmm... that makes sense
[07:20:58 CDT(-0500)] <EricDalquist> http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/spring.tld.html#spring.tld.message
[07:21:09 CDT(-0500)] <EricDalquist> you could probably create several variations on that one static method
[07:21:18 CDT(-0500)] <EricDalquist> with the various options
[07:21:52 CDT(-0500)] <EricDalquist> the hardest bit, and if this is a road block I can take a look, is that right now you can only return text, no markup can be returned by the message tag in the XSL
[07:22:01 CDT(-0500)] <Arvids> yes, but first i'd like to talk to athena - how can i compose such comma-sperated string if i want to pass more than one argument
[07:22:30 CDT(-0500)] <Arvids> oh, yeah... that would really help
[07:22:54 CDT(-0500)] <EricDalquist> I "think" this would work: '{$SOME_VAR1},{$SOME_VAR2},test'
[07:22:56 CDT(-0500)] <Arvids> that would allow to translate all those footer messages
[07:23:06 CDT(-0500)] <Arvids> hmmm.... i'll try that
[07:23:35 CDT(-0500)] <Arvids> ok, i'll dive in the code now
[07:23:44 CDT(-0500)] <EricDalquist> yeah the problem is since these java callbacks are being called from an XSLT processor if we want to return markup we have to return them as actual XML Node objects
[07:23:56 CDT(-0500)] <EricDalquist> so I think what would have to happen is that method would need to return a NodeList
[07:24:26 CDT(-0500)] <EricDalquist> and the logic in the method would have to get the message string and then do XML parsing on it to turn it into a list of element and text nodes
[07:24:40 CDT(-0500)] <EricDalquist> and it would have to be well formatted XML, no hanging tags, etc
[07:24:47 CDT(-0500)] <EricDalquist> I think its probably doable
[07:24:59 CDT(-0500)] <EricDalquist> just not a trivial case
[07:25:11 CDT(-0500)] <Arvids> indeed
[07:25:49 CDT(-0500)] <EricDalquist> as for the DB storage bit of it
[07:26:01 CDT(-0500)] <EricDalquist> uportal-war/src/main/resources/properties/contexts/mvcContext.xml defines the messageSource bean
[07:26:19 CDT(-0500)] <Arvids> ahh... there's one spring issue (closed, though) which we can use
[07:26:32 CDT(-0500)] <Arvids> https://jira.springsource.org/browse/SPR-364
[07:27:07 CDT(-0500)] <Arvids> but there are too many questions regarding caching...
[07:27:13 CDT(-0500)] <EricDalquist> oh neat
[07:27:28 CDT(-0500)] <EricDalquist> well the portal uses ehcache for everything
[07:27:33 CDT(-0500)] <EricDalquist> so that would be the easy answer
[07:27:41 CDT(-0500)] <EricDalquist> even better would be to make it consistent with the rest of the new portal DAOs
[07:27:43 CDT(-0500)] <EricDalquist> and use JPA2
[07:27:50 CDT(-0500)] <EricDalquist> then caching is handled by hibernate
[07:28:02 CDT(-0500)] <EricDalquist> including all of the stuff around clearing cachie on update
[07:28:27 CDT(-0500)] <Arvids> sounds nice
[07:29:26 CDT(-0500)] <Arvids> btw, is there any written policies regarding svn commits?
[07:29:28 CDT(-0500)] <EricDalquist> I've been trying to document guidelines for various things here: https://wiki.jasig.org/display/UPC/uPortal+Developers
[07:29:45 CDT(-0500)] <EricDalquist> as for SVN commits, we just try to reference the jira issue ID in the commit
[07:30:05 CDT(-0500)] <Arvids> ok, i've seen that
[07:31:02 CDT(-0500)] <Arvids> as i understand, JIRA issue should be mentioned if there is one, but if there isn't... should i create one?
[07:31:24 CDT(-0500)] <Arvids> for example, i'll work on improving i18n support
[07:31:35 CDT(-0500)] <Arvids> but this'll be ongoing work
General
Content
Integrations