[12:14:36 CST(-0600)] <holdorph> EricDalquist, your respons on uportal-dev.... you asked what version of uPortal. But I thought he stated that in the first line of the original message "in current trunk"
[12:15:22 CST(-0600)] <EricDalquist> thanks holdorph
[12:15:26 CST(-0600)] <EricDalquist> been a crazy mornig
[12:15:51 CST(-0600)] <holdorph> nod he's just in Europe, so didn't seem worth waiting another whole day for him to respond.
[12:15:57 CST(-0600)] <EricDalquist> ah yeah
[12:16:23 CST(-0600)] <holdorph> actually, come to think of it, I don't know for sure where '.edu.mk' is
[12:17:14 CST(-0600)] <holdorph> lol, but http://www.ii.edu.mk/ is 'powered by uPortal 2.6.0'
[12:40:11 CST(-0600)] <EricDalquist> hrm ... I think the gallery patch may have reverted the channel list controller so you don't see channels that are not under All Categories in portlet manager ...
[13:01:26 CST(-0600)] <ajan> Hi, I am actually here - Vangel Ajanovski
[13:01:37 CST(-0600)] <EricDalquist> oh hello
[13:01:52 CST(-0600)] <EricDalquist> so I think athena is right, it is likely an issue with how the cache key for the root layout document is generated
[13:02:00 CST(-0600)] <ajan> i am always here but most of the time do not open the window
[13:02:01 CST(-0600)] <EricDalquist> that is on the list of things to do for trunk
[13:03:02 CST(-0600)] <ajan> ok, it is not a huge problem at the moment, since I'm just experimenting
[13:03:31 CST(-0600)] <athena> EricDalquist: isn't that something you mentioned might be an issue in 3.2.x as wel?
[13:03:44 CST(-0600)] <athena> or maybe i'm thinking of the portlet titles in the flyout menu issues
[13:03:45 CST(-0600)] <EricDalquist> the cache key generation?
[13:03:48 CST(-0600)] <EricDalquist> oh yeah
[13:04:00 CST(-0600)] <EricDalquist> it was for portlet titles
[13:04:04 CST(-0600)] <EricDalquist> but I think that's been fixed
[13:04:28 CST(-0600)] <ajan> holdorph: edu.mk is in Macedonia (North of Greece, South of Serbia, West of Bulgaria, East of Albania to be more precise
[13:04:36 CST(-0600)] <athena> oh ok, cool
[13:06:19 CST(-0600)] <ajan> OK, while I'm here ... I am trying to upgrade everything we have from 2.6.? to 3.x and I planned to finish til Dec, 15. Is there any possibility that the many such small annoyances would be fixed in trunk by that time? What is the schedule for 3.3?
[13:06:40 CST(-0600)] * athena notes that ajan is the kind soul who offered to help translate uportal into macedonian
[13:06:47 CST(-0600)] <EricDalquist> no way I would recommend 3.3 for december
[13:06:54 CST(-0600)] <EricDalquist> we're still a few months away from an RC
[13:07:05 CST(-0600)] <EricDalquist> and until that point we will be making a few more big DB changes
[13:07:15 CST(-0600)] <EricDalquist> nothing near stable enough that you'd want to deploy on
[13:07:31 CST(-0600)] <EricDalquist> If I were doing a new portal install or upgrade 3.3 would be what I would target for June
[13:07:51 CST(-0600)] <ajan> OK ... well I hoped .... we are still running 2.6.0 from trunk freezed at a moment before 2.6 was released
[13:08:50 CST(-0600)] <athena> upgrading to 3.2.x would probably be a much better choice - should get you a bunch of nice new features and be part-way to 3.3
[13:09:27 CST(-0600)] <EricDalquist> right 3.2 to 3.3 will be significantly less work than 2.x to any 3.x
[13:09:40 CST(-0600)] <EricDalquist> so you're not really doubling or wasting efforts by going to 3.2
[13:11:13 CST(-0600)] <ajan> i guess it certainly will be easier, I still have all the xsl changes to redo in order to enable our support for both english and macedonian on the guest page
[13:12:12 CST(-0600)] <ajan> so I'm not really sure how different is 3.x from 2.x in respect to this
[13:12:24 CST(-0600)] <athena> hm, guess the i18n stuff is kind of an issue
[13:12:33 CST(-0600)] <athena> since all that work is specific to 3.3
[13:13:39 CST(-0600)] <ajan> athena: as I mention on the -user list I have already checked and corrected the Macedonian translation and I think it's 90-95% correct and the rest is understandable
[13:14:21 CST(-0600)] <athena> i saw that - that's fantastic
[13:14:32 CST(-0600)] <athena> i'm not sure what we want the eventual process to be for updating those files
[13:14:40 CST(-0600)] <athena> but i guess for now you could just email it to me or something
[13:14:52 CST(-0600)] <ajan> but in 2.6 there were many places in the xsl files where it was lang="en" and I had to put in some extra logic that will get the locale from the framework and present different strings or content depending if it was "mk" or "en"
[13:16:30 CST(-0600)] <athena> gotcha
[13:16:43 CST(-0600)] <athena> i think there's less of that in 3.2
[13:16:58 CST(-0600)] <ajan> I hope so
[13:39:55 CST(-0600)] <EricDalquist> heh athena the type=manage parameter got lost in the gallery patch for the portlet admin UI
[13:40:04 CST(-0600)] <EricDalquist> so you don't see root-less portlets
[13:40:14 CST(-0600)] <athena> oh!
[13:40:19 CST(-0600)] <athena> well that's bad
[13:43:52 CST(-0600)] <EricDalquist> athena or mpolizzotti any idea which JS file(s) house the logic for searching in both the portlet manager and in the gallery?
[13:44:11 CST(-0600)] <EricDalquist> since we switched to using channel titles instead of names the searching is a bit funky
[13:44:34 CST(-0600)] <athena> hmm
[13:44:53 CST(-0600)] <athena> should be able to inject urls into the portlet browser component
[13:44:57 CST(-0600)] <mpolizzotti> I'm in that area right now...I can take a look.
[13:45:17 CST(-0600)] <athena> i'd probably add logic to the preferences.xsl to inject either the manage or normal URL into the main component
[13:45:29 CST(-0600)] <athena> rather than adding some sort of is-admin syntax to all the js components
[13:45:44 CST(-0600)] <EricDalquist> looks like maybe up-portlet-browers.js
[13:45:45 CST(-0600)] <athena> though . . .
[13:45:50 CST(-0600)] <athena> you know, i really don't think that's right
[13:46:09 CST(-0600)] <EricDalquist> athena: for the type=manage fix it is an easy change
[13:46:12 CST(-0600)] <EricDalquist> just in the JSP for the flow
[13:46:13 CST(-0600)] <athena> EricDalquist: are you looking at the main UI to add a portlet or the portlet admin channel?
[13:46:21 CST(-0600)] <athena> ah ok
[13:46:27 CST(-0600)] <athena> so yes, in that case it's just a fix to the JSP
[13:46:29 CST(-0600)] <EricDalquist> sorry I had two issues
[13:46:31 CST(-0600)] <athena> no editing of js code
[13:46:37 CST(-0600)] <EricDalquist> one was the manage parameter
[13:46:51 CST(-0600)] <EricDalquist> the other one now is having the JS search also search on name & fname
[13:46:57 CST(-0600)] <EricDalquist> for both subscribe and admin
[13:47:13 CST(-0600)] <athena> ok, so the manage parameter is just the in-JSP url
[13:47:25 CST(-0600)] <EricDalquist> yup, found and fixed that one
[13:47:27 CST(-0600)] <athena> search is actually implemented in each display, kind of
[13:47:39 CST(-0600)] <athena> it's not part of the base component
[13:47:58 CST(-0600)] <athena> so for the admin tool, i think there's a portlet listing component in the JSP itself
[13:48:31 CST(-0600)] <athena> and if you want that search changed for the user-facing stuff in the layout, it'd be in up-layout-gallery (AjaxLayoutPortletListView)
[13:50:42 CST(-0600)] <EricDalquist> ok
[13:53:19 CST(-0600)] <EricDalquist> so is searching part of the pager then?
[13:54:29 CST(-0600)] <EricDalquist> actually I think I found it for the admin UI
[14:00:52 CST(-0600)] <athena> oh good, sorry
[14:01:02 CST(-0600)] <athena> the search is part of the portlet listing subcomponent
[14:01:22 CST(-0600)] <athena> which is different for the admin ui and the preferences
[14:01:27 CST(-0600)] <athena> both of which happen to use a pager
[14:01:37 CST(-0600)] <EricDalquist> it looks like both gallery and portlet manager use logic in up-layout-gallery
[14:01:40 CST(-0600)] <EricDalquist> as far as I can tell
[14:01:53 CST(-0600)] <athena> they do
[14:02:28 CST(-0600)] <athena> but they also use custom portlet listing components
[14:02:40 CST(-0600)] <athena> you want line 310 of listChannels.jsp
[14:02:46 CST(-0600)] <athena> see where it uses the regex?
[14:03:12 CST(-0600)] <EricDalquist> oh yeah
[14:03:14 CST(-0600)] <athena> so the main component tracks the regex, but it's up to the subview to actually use it
[14:03:15 CST(-0600)] <EricDalquist> not sure how I missed that
[14:03:35 CST(-0600)] <athena> since it's possible that some components might want to implement search differently (fname vs. not or whatever)
[14:20:46 CST(-0600)] <athena> uhoh
[14:20:55 CST(-0600)] <athena> EricDalquist: it looks like jasig jira is down?
[14:24:30 CST(-0600)] <EricDalquist> hrm
[14:25:47 CST(-0600)] <EricDalquist> just emailed contegix
[14:32:49 CST(-0600)] <athena> thanks
[14:49:55 CST(-0600)] <EricDalquist> athena: try it now?
[14:50:13 CST(-0600)] <athena> hurray!
[14:50:20 CST(-0600)] <athena> thanks
[14:50:29 CST(-0600)] <EricDalquist> heh I just emailed contegix
[14:50:44 CST(-0600)] <EricDalquist> they just did their usual awesomeness
[14:50:45 CST(-0600)] <athena> still appreciated
[14:50:48 CST(-0600)] <athena> yeah
[14:50:55 CST(-0600)] <athena> really nice to have stuff fixed that quickly!
[14:50:58 CST(-0600)] <EricDalquist> yup
[17:55:26 CST(-0600)] <Bananobot> I have an AbstractController I'm using for a portlet. In the handleRenderRequestInternal method, I check whether request.getParameter("institution") is null to decide which view to use. However, it seems to always be null, even if the page's URL targets the portlet and contains the GET parameter (/render.userLayoutRootNode.target.n62.uP?institution=foo)
[17:56:05 CST(-0600)] <Bananobot> Am I approaching this wrong?
[17:56:34 CST(-0600)] <Bananobot> (I'd rather not use a higher level of abstraction like Web Flow, since I'm still learning the basics)
[18:03:48 CST(-0600)] <Bananobot> Hm... I'm reading that handleRenderRequestInternal isn't supposed to get the original request parameters, but that handleActionRequestInternal is...

Browser not supported