uPortal IRC Logs-2011-09-13

[09:40:23 CDT(-0500)] <Arvids> hi, everyone!
[09:40:35 CDT(-0500)] <Arvids> could someone help me to understand the PortletDefinition manipulation API?
[09:43:55 CDT(-0500)] <Arvids> Ahhh... i believe email lists will be the right solution (smile)
[09:56:16 CDT(-0500)] <Arvids> hey, Eric!
[09:56:43 CDT(-0500)] <Arvids> I'm glad to see you here - if you have 5 minutes to spare i'd like to ask you some questions
[09:58:48 CDT(-0500)] <EricDalquist> sure, just a few minutes
[09:58:59 CDT(-0500)] <EricDalquist> and I'll be availble
[09:59:48 CDT(-0500)] <Arvids> ok, i'll start explaining the situation around translations
[10:00:38 CDT(-0500)] <Arvids> i've implemented a simple database-based message source, but also i would like someone to review the changes
[10:01:57 CDT(-0500)] <Arvids> how that should be done? Just commit to SVN and then correcting the (possble) weak places?
[10:02:22 CDT(-0500)] <Arvids> another question is regarding translation portlet - i can't get my head round it...
[10:03:38 CDT(-0500)] <Arvids> If i need to translate the portlet definition, then from one point of view i'd like to see thos translations in portlet management view...
[10:04:35 CDT(-0500)] <Arvids> current implementation requires IPortletDefinition changes in order to do that
[10:05:10 CDT(-0500)] <Arvids> ... because there's no easy way how to retrieve all translated data
[10:06:09 CDT(-0500)] <Arvids> on the other hand - someone might consider special translation portlet a better solution, because the i can delegate permissions to non-administrator in order to translate all the messages
[10:06:23 CDT(-0500)] <EricDalquist> for now just a commit to svn and I'll take a look (in the future this is why git would be really handy, you could commit to your own fork and do a pull request which could then be reviewed)
[10:06:45 CDT(-0500)] <Arvids> ok
[10:07:15 CDT(-0500)] <EricDalquist> yeah I think before we look at changing the data model we need some better ideas on what the UIs should look like
[10:07:27 CDT(-0500)] <Arvids> indeed
[10:07:32 CDT(-0500)] <EricDalquist> there are really a few parts to having better support for translating data
[10:07:46 CDT(-0500)] <EricDalquist> we need the exported XML data model to support the translations
[10:08:03 CDT(-0500)] <Arvids> hmm... haven't thought about that before
[10:08:10 CDT(-0500)] <Arvids> but it makes sense
[10:08:19 CDT(-0500)] <EricDalquist> that's not as hard, we just start using the xml:lang attribute and update the XSDs to allow for things like multiple <name> elements as long as they all have unique xml:lang values
[10:08:33 CDT(-0500)] <EricDalquist> then we need to figure out how the runtime UI would work
[10:08:43 CDT(-0500)] <EricDalquist> like you said ... do we make it part of the portlet management UI?
[10:09:09 CDT(-0500)] <Arvids> well... that's one very basic question
[10:09:22 CDT(-0500)] <EricDalquist> or do we have a separate "translations portlet" which allows you to pick a piece of translatable portal data and enter translations for it
[10:09:31 CDT(-0500)] <EricDalquist> or are there other options?
[10:09:50 CDT(-0500)] <Arvids> there's always a solution of tinkering the database data directly (big grin)
[10:09:50 CDT(-0500)] <EricDalquist> also how do we deal with the "default" text versus locale specific text?
[10:09:58 CDT(-0500)] <EricDalquist> hah (smile)
[10:10:20 CDT(-0500)] <EricDalquist> so here is a question for you
[10:10:41 CDT(-0500)] <EricDalquist> in the default uPortal 4 setup we have the english translations in the default messages file
[10:10:48 CDT(-0500)] <Arvids> ok, i believe i'll have to write to the uportal-user list in order to gather some opinions about that
[10:10:50 CDT(-0500)] <EricDalquist> so if no translation is found english is used
[10:11:01 CDT(-0500)] <EricDalquist> when you're translating to your native locale
[10:11:13 CDT(-0500)] <EricDalquist> do you copy the english messages file to messages_en.properties
[10:11:31 CDT(-0500)] <EricDalquist> and then translate the default properties file to your native locale?
[10:11:40 CDT(-0500)] <EricDalquist> I've always wondered what the best practice is there
[10:11:50 CDT(-0500)] <Arvids> i'm using ResourceBundle editor
[10:12:03 CDT(-0500)] <Arvids> i'm sure someone has mentioned it on the lists
[10:12:16 CDT(-0500)] <EricDalquist> part of me wonders if we should tweak our build process a bit so that we don't have a "default" messages.properties file in svn
[10:13:02 CDT(-0500)]

<EricDalquist> and in maven we specific the default locale, for example "en", and at build time the build copies "messages_$

Unknown macro: {defaultLocale}

.properties" to messages.properties


[10:13:06 CDT(-0500)] <Arvids> that would be dangerous...
[10:13:28 CDT(-0500)] <Arvids> i believe english locale is better than keywords if the specific locale file is missing
[10:13:40 CDT(-0500)] <EricDalquist> ok
[10:13:51 CDT(-0500)] <EricDalquist> and that's the easy solution (smile)
[10:14:00 CDT(-0500)] <EricDalquist> back to the translations UI
[10:14:04 CDT(-0500)] <EricDalquist> and email to the user list would be good
[10:14:14 CDT(-0500)] <EricDalquist> to see what people are interested in for ways to translate
[10:14:56 CDT(-0500)] <Arvids> i'm wondering why esup community is so passive in this area :/
[10:15:20 CDT(-0500)] <EricDalquist> yeah, they seem to just take what we produce with uPortal and customize/use it
[10:15:25 CDT(-0500)] <Arvids> it's of their direct interest in order to improve i18n
[10:15:27 CDT(-0500)] <EricDalquist> but there isn't a ton of collaboration
[10:15:36 CDT(-0500)] <EricDalquist> we've tried in the past but part of the problem has been language barriers
[10:15:36 CDT(-0500)] <Arvids> yes
[10:15:57 CDT(-0500)] <EricDalquist> since all of us US folks are sadly monolingual
[10:16:19 CDT(-0500)] <Arvids> yeah, i'm getting used to that...
[10:17:19 CDT(-0500)] <Arvids> ok, i have to go now
[10:17:22 CDT(-0500)] <EricDalquist> ok
[10:17:24 CDT(-0500)] <Arvids> I'll write an email to user list tomorrow
[10:17:30 CDT(-0500)] <EricDalquist> Sounds good
[10:17:38 CDT(-0500)] <EricDalquist> I'll bug athena a bit for some ideas as well
[10:17:46 CDT(-0500)] <EricDalquist> so that she and I can reply to that email with some ideas (smile)
[10:17:51 CDT(-0500)] <Arvids> and now i'll commit those changes regarding database message source
[10:17:56 CDT(-0500)] <EricDalquist> sounds good
[10:23:35 CDT(-0500)] <Arvids> done
[10:23:47 CDT(-0500)] <Arvids> bye...
[10:33:18 CDT(-0500)] * athena appears
[10:33:25 CDT(-0500)] <EricDalquist> hello athena
[10:33:43 CDT(-0500)] <EricDalquist> you might be interested in reading the conversation Arvids and I had this morning
[10:33:52 CDT(-0500)] <EricDalquist> about how to setup an i18n UI
[10:34:29 CDT(-0500)] <athena> yep, just read up
[10:34:45 CDT(-0500)] <athena> sounds helpful
[10:34:54 CDT(-0500)] <athena> brb - need to restart my IM client
[10:35:50 CDT(-0500)] <EricDalquist> so any ideas on the "best" way to do a UI to allow translation of portlet/tab/group data?
[10:36:03 CDT(-0500)] <EricDalquist> I kinda like the idea of a dedicated translation admin ui
[10:36:12 CDT(-0500)] <EricDalquist> with a set of assocated permissions
[10:36:12 CDT(-0500)] <athena> my general thought is that the best UI is one that you and i don't create (tongue)
[10:36:17 CDT(-0500)] <EricDalquist> lol
[10:36:24 CDT(-0500)] <athena> but yeah, in general i think that's a good idea
[10:36:37 CDT(-0500)] <athena> by the way, did you see my email about resource URLs?
[10:36:52 CDT(-0500)] <EricDalquist> I'm just thinking that trying to add delegated localization permissions to the existing admin UIs might be a bit much
[10:36:53 CDT(-0500)] <EricDalquist> yes
[10:37:01 CDT(-0500)] <athena> yeah, i think that's true
[10:37:03 CDT(-0500)] <EricDalquist> so I had a question ... trying to remember it
[10:37:31 CDT(-0500)] <EricDalquist> oh ... so are the URLs working right now?
[10:37:36 CDT(-0500)] <EricDalquist> just an extra redirect?
[10:37:49 CDT(-0500)] <athena> well . . .
[10:37:55 CDT(-0500)] <athena> sort of
[10:38:36 CDT(-0500)] <athena> there's also some really weird behavior where it looks like the redirected (normal) URL works correctly in the mobile theme and not so much in desktop
[10:38:41 CDT(-0500)] <athena> like maybe it loses some session state or something
[10:38:45 CDT(-0500)] <athena> something very strange like that
[10:39:00 CDT(-0500)] <EricDalquist> hrm
[10:39:06 CDT(-0500)] <athena> but haven't debugged all that, since what we really want is not to be doing a 302 redirect, since that'll certainly impact performance
[10:39:16 CDT(-0500)] <EricDalquist> so detached portlet windows are a little different
[10:39:17 CDT(-0500)] <athena> would think if we just fix the URL redirecting behavior it should all work as expected
[10:39:27 CDT(-0500)] <EricDalquist> since they have no session perisistent state, it is all encoded on the URL
[10:39:46 CDT(-0500)] <EricDalquist> I need to re-read the resource request stuff in the portlet spec
[10:40:10 CDT(-0500)] <EricDalquist> so it looks like resource requests are state/mode aware
[10:40:28 CDT(-0500)] <EricDalquist> I can take a look at the unit test later today
[10:40:42 CDT(-0500)] <EricDalquist> first day back in the office after being gone for more than a week ... lots of catching up to do
[10:41:02 CDT(-0500)] <athena> i bet (smile)
[10:41:38 CDT(-0500)] <athena> so actually resource requests should know about state/mode? is that what you're saying?
[10:41:51 CDT(-0500)] <EricDalquist> yes
[10:42:07 CDT(-0500)] <EricDalquist> ResourceRequest extends from PortletRequest
[10:42:13 CDT(-0500)] <EricDalquist> which has getWindowState and getPortletMode method
[10:42:15 CDT(-0500)] <EricDalquist> s
[10:46:47 CDT(-0500)] <athena> gotcha
[11:53:55 CDT(-0500)] <athena> EricDalquist: is nick around today?
[11:54:02 CDT(-0500)] <EricDalquist> he was
[11:54:07 CDT(-0500)] <EricDalquist> he's off to a golf tourney
[11:54:10 CDT(-0500)] <athena> ah (smile)
[11:54:14 CDT(-0500)] <athena> been looking at this caching stuff
[11:54:32 CDT(-0500)] <athena> think we maybe have two separate use cases w/ the resource caching stuff
[11:54:39 CDT(-0500)] <athena> one where we actually genuinely want to replay cached content
[11:54:51 CDT(-0500)] <athena> and one where we don't and want to just send back a 302 redirect
[11:54:56 CDT(-0500)] <athena> might need to talk all that through
[11:55:24 CDT(-0500)] <athena> not sure if our data model totally supports it
[11:56:13 CDT(-0500)] <EricDalquist> is it an additional branch not covered by the diagram herE: https://wiki.jasig.org/display/UPC/JSR-286+Caching+Use+Cases
[11:57:47 CDT(-0500)] <athena> yeah, i think we're going to need to add to that diagram
[11:57:57 CDT(-0500)] <EricDalquist> ok
[11:58:00 CDT(-0500)] <athena> first of all, we might not actually have cached content to replay
[11:58:16 CDT(-0500)] <athena> if the etag still matches, but the expiration timeout has been exceeded, then i think the portal doesn't have the content to replay anymore
[11:58:30 CDT(-0500)] <EricDalquist> it might
[11:58:36 CDT(-0500)] <athena> but not guaranteed
[11:58:38 CDT(-0500)] <EricDalquist> depends on if it has been purged from the cache
[11:58:40 CDT(-0500)] <EricDalquist> right
[11:58:53 CDT(-0500)] <athena> and also beyond that, if the browser already has it, we don't actually want to send that back in the response; i think we want to send back an empty response with the appropriate response code
[11:59:04 CDT(-0500)] <EricDalquist> it is always the case that cached content can just disappear from the portal's content cache
[11:59:11 CDT(-0500)] <EricDalquist> yup
[11:59:14 CDT(-0500)] <EricDalquist> which is there now
[11:59:18 CDT(-0500)] <EricDalquist> and just missing in that diagram
[11:59:59 CDT(-0500)] <athena> which thing is there now?
[12:00:23 CDT(-0500)] <EricDalquist> I believe the portal should be sending a 304 if the etag is valid
[12:00:29 CDT(-0500)] <EricDalquist> even if the cached content is missing
[12:00:39 CDT(-0500)] <EricDalquist> upsc call time (tongue)
[12:00:44 CDT(-0500)] <athena> yeah, calling in (smile)
[12:01:03 CDT(-0500)] <athena> dunno, i don't think it is sending back 304 responses
[12:01:35 CDT(-0500)] <EricDalquist> I know he had verified that in his testing
[12:01:38 CDT(-0500)] <athena> ok
[12:01:41 CDT(-0500)] <athena> i'll take a look
[12:01:52 CDT(-0500)] <EricDalquist> and I thought you had too
[12:01:58 CDT(-0500)] <EricDalquist> after you stopped POSTing to the resource url (wink)
[12:02:04 CDT(-0500)] <athena> yeah . . .
[12:02:05 CDT(-0500)] <athena> lol
[12:02:23 CDT(-0500)] <athena> i think maybe i saw it when i was setting the expiration timeout
[12:02:43 CDT(-0500)] <EricDalquist> yeah you do have to set an expiration timeout
[12:04:44 CDT(-0500)] <athena> seems to only work if the timeout hasn't been exceeded
[12:05:18 CDT(-0500)] <EricDalquist> ah
[12:46:47 CDT(-0500)] <EricDalquist> athena: that url bug is in the canonicalization code
[12:46:51 CDT(-0500)] <EricDalquist> trying to figure out a fix now
[12:47:23 CDT(-0500)] <athena> one of the things i noticed is in UrlSyntaxProviderImpl.determineUrlState
[12:47:36 CDT(-0500)] <athena> has a test to set the requested window state to null if it's a resource URL
[12:48:35 CDT(-0500)] <athena> but even then the method won't really return the right state because the targetedPortletUrlBuidler returns a null window state
[12:48:42 CDT(-0500)] <athena> wasn't quite sure where to go from there
[12:53:02 CDT(-0500)] <EricDalquist> yeah I think its just a problem with some conflicting assumptions of DETACHED and resource urls
[12:54:42 CDT(-0500)] <athena> gotcha
[12:57:02 CDT(-0500)] <athena> yeah, that's a good point
[12:57:08 CDT(-0500)] <athena> because i don't think this is happening in maximized
[13:35:02 CDT(-0500)] <EricDalquist> oi ... brain is still warming back up after being on vacation
[13:35:30 CDT(-0500)] <athena> yeah i hear that
[13:53:28 CDT(-0500)] <EricDalquist> athena: I think I have a fix for that url problem
[13:53:44 CDT(-0500)] <athena> YAY
[13:53:46 CDT(-0500)] <athena> that's great news
[13:54:02 CDT(-0500)] <EricDalquist> the new unit tests pass at least (tongue)
[13:54:28 CDT(-0500)] <athena> well that's a start (smile)
[15:29:00 CDT(-0500)] <EricDalquist> athena: was there a jira issue for that detached url bug?
[15:29:11 CDT(-0500)] <athena> no
[15:29:24 CDT(-0500)] <EricDalquist> ok
[15:31:07 CDT(-0500)] <EricDalquist> https://issues.jasig.org/browse/UP-3164
[15:31:37 CDT(-0500)] <EricDalquist> ok athena I just committed a fix
[15:31:41 CDT(-0500)] <EricDalquist> I did some basic testing
[15:31:46 CDT(-0500)] <EricDalquist> and it appears to behave correctly
[15:32:06 CDT(-0500)] <athena> awesome, i'll try it out
[15:32:07 CDT(-0500)] <athena> thanks (smile)
[15:35:17 CDT(-0500)] <athena> will i need r24978 as well?
[15:50:38 CDT(-0500)] <athena> just used the portlet archetype for the first time
[15:50:42 CDT(-0500)] <athena> super useful, i think