[03:16:33 EDT(-0400)] * higmad (n=chatzill@pcit-8752.HIG.SE) has joined ##uportal
[08:49:14 EDT(-0400)] * anastasiac (n=stasia@142.150.154.189) has joined ##uportal
[08:54:10 EDT(-0400)] * athena (n=athena@99.129.100.66) has joined ##uportal
[09:11:28 EDT(-0400)] * bszabo (n=bszabo@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[09:21:18 EDT(-0400)] * fj4000 (n=Jacob@142.150.154.106) has joined ##uportal
[09:26:16 EDT(-0400)] * jessm (n=Jess@c-71-232-1-65.hsd1.ma.comcast.net) has joined ##uportal
[09:28:48 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[09:36:39 EDT(-0400)] * lennard1 (n=sparhk@ip68-98-56-21.ph.ph.cox.net) has joined ##uportal
[09:53:40 EDT(-0400)] * michelled (n=team@142.150.154.193) has joined ##uportal
[10:15:18 EDT(-0400)] * dstn (n=dstn@unaffiliated/dstn) has joined ##uportal
[10:16:25 EDT(-0400)] <dstn> When using the "Use it Now" what windowState does that put the portlet in? It appears to be maximized but renderRequest.windowState does not equal maximized...
[10:16:41 EDT(-0400)] <EricDalquist> it should be maximized
[10:16:53 EDT(-0400)] <EricDalquist> but that event may not be getting sent to the portlet correctly
[10:17:48 EDT(-0400)] <dstn> ok, I'll file a jira so its not lost
[10:19:43 EDT(-0400)] * jessm (n=Jess@c-71-232-1-65.hsd1.ma.comcast.net) has joined ##uportal
[10:21:57 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[10:22:31 EDT(-0400)] <athena> do you think it's a problem w/ the URL generated by the AJAX?
[10:23:03 EDT(-0400)] <EricDalquist> it could be
[10:23:22 EDT(-0400)] <EricDalquist> it may not be setting the correct parameters to trigger the maximized event
[10:23:30 EDT(-0400)] <athena> yeah, that's kind of what i was thinking
[10:23:37 EDT(-0400)] <athena> i can take a quick look at if if you want
[10:24:14 EDT(-0400)] <athena> i can at least see if anything's different between the icon links and the one in the ajax dialog
[10:24:34 EDT(-0400)] <EricDalquist> oh, I actually have a start on the url work
[10:24:59 EDT(-0400)] <athena> oh cool!
[10:25:01 EDT(-0400)] <EricDalquist> I'll probably be looking for some insight later today to make sure I'm not forgetting things in the API design
[10:25:11 EDT(-0400)] <athena> that's great
[10:25:30 EDT(-0400)] <EricDalquist> like does the theme XSL ever need to be able to change the general window state
[10:25:41 EDT(-0400)] <EricDalquist> I'm thinking it needs to be able to request switching back to 'normal'
[10:26:06 EDT(-0400)] <EricDalquist> but any other state would require targeting a channel, and channel urls will have complete WindowState support
[10:26:52 EDT(-0400)] <athena> ah
[10:27:23 EDT(-0400)] <EricDalquist> so the idea right is different URL object types
[10:27:59 EDT(-0400)] <EricDalquist> like a PortalLayoutUrl would have portal parameters and the ability to reset the window state to normal
[10:28:22 EDT(-0400)] <athena> sounds good
[10:28:32 EDT(-0400)] <athena> i just looked at the thing dstn reported
[10:28:42 EDT(-0400)] <athena> looks like the ajax url actually contains more info, not less
[10:28:57 EDT(-0400)] <EricDalquist> you know
[10:28:58 EDT(-0400)] <athena> the icons link to render.userLayoutRootNode.uP?uP_root=u13l1n11 or the like
[10:29:04 EDT(-0400)] <EricDalquist> this could be a bug I recently fixed locally
[10:29:20 EDT(-0400)] <athena> the ajax "use it now" link includes the active tab
[10:29:35 EDT(-0400)] <EricDalquist> where the first time you target a portlet not all of the URL parameters actually get processed correctly
[10:29:58 EDT(-0400)] <athena> er, hm, maybe i'm looking at it wrong
[10:30:00 EDT(-0400)] <athena> oh, interesting
[10:30:05 EDT(-0400)] <athena> and that's definitely a first target
[10:30:39 EDT(-0400)] <athena> ok, here we go
[10:30:42 EDT(-0400)] <EricDalquist> I'll check into any local mods we may have
[10:30:46 EDT(-0400)] <athena> the link just goes to uP_fname=
[10:30:51 EDT(-0400)] <EricDalquist> also check in the 3.1 patches branch
[10:30:52 EDT(-0400)] <EricDalquist> ah
[10:30:53 EDT(-0400)] <EricDalquist> yeah
[10:30:56 EDT(-0400)] <EricDalquist> that was the bug
[10:31:09 EDT(-0400)] <athena> ok
[10:32:04 EDT(-0400)] <EricDalquist> it may be http://www.ja-sig.org/issues/browse/UP-2366
[10:32:30 EDT(-0400)] <dstn> yes, its the same
[10:32:40 EDT(-0400)] <dstn> since it just uses fname
[10:32:49 EDT(-0400)] <dstn> I'll mark it as dup
[10:34:16 EDT(-0400)] <athena> eric i may have a few extra min this week and sunday
[10:34:42 EDT(-0400)] <athena> i've got two JIRAs on the up 3.1.1 list
[10:34:58 EDT(-0400)] <athena> would you want me to look at those, or is it feeling late for fixes?
[10:35:19 EDT(-0400)] <EricDalquist> go ahead
[10:35:30 EDT(-0400)] <athena> ok
[10:36:01 EDT(-0400)] <athena> i assume you'll send something out when you want to freeze the branch? i just don't want to get in your way
[10:36:43 EDT(-0400)] <dstn> actually wait, UP-2366 says it was fixed in 3.1 – this is what we're using
[10:37:43 EDT(-0400)] <EricDalquist> let me verify the issue id
[10:39:29 EDT(-0400)] <dstn> k, let me see if someone here has a vanilla 3.1 with test portlet
[10:39:40 EDT(-0400)] <EricDalquist> it isn't fixed in 3.1
[10:39:50 EDT(-0400)] <EricDalquist> I just did the fix a few weeks ago
[10:41:08 EDT(-0400)] <athena> so it just needs it's jira info updated?
[10:41:50 EDT(-0400)] <EricDalquist> it may be a different jira issue
[10:42:36 EDT(-0400)] <athena> eric did we decide to do anything about the column issue yale reported in 3.1? i don't see a jira for it
[10:42:38 EDT(-0400)] <EricDalquist> http://www.ja-sig.org/issues/browse/UP-2423
[10:42:44 EDT(-0400)] <EricDalquist> ?
[10:43:05 EDT(-0400)] <EricDalquist> I can't remember what they reported
[10:43:10 EDT(-0400)] <dstn> ok, that sounds right
[10:43:13 EDT(-0400)] <dstn> sry
[10:43:32 EDT(-0400)] <athena> basically schools that used the experimental ajax features in 2.6 wound up with data that marked columns as arbitrary widths
[10:43:40 EDT(-0400)] <EricDalquist> dstn: no problem
[10:43:47 EDT(-0400)] <EricDalquist> oh
[10:43:49 EDT(-0400)] <athena> so you might have one that's 25.6983% width
[10:43:54 EDT(-0400)] <athena> and the current theme doesn't handle it
[10:43:56 EDT(-0400)] <EricDalquist> a jira would be good
[10:44:05 EDT(-0400)] <athena> dstn: did you ever file one for that?
[10:44:11 EDT(-0400)] <EricDalquist> I think we talked about adding support for 100 different CSS classes
[10:44:14 EDT(-0400)] <athena> yeah
[10:44:19 EDT(-0400)] <dstn> I did not
[10:44:20 EDT(-0400)] <dstn> I can though
[10:44:40 EDT(-0400)] <athena> EricDalquist: i think that's right - doing that, then rounding down the width attribute?
[10:44:49 EDT(-0400)] <athena> dstn: that'd be awesome, if you don't mind
[10:44:59 EDT(-0400)] <athena> that was the other thing i was thinking of trying to get fixed for 3.1.1
[10:44:59 EDT(-0400)] <EricDalquist> athena: yeah
[10:45:12 EDT(-0400)] <athena> i think rounding down is probably safest
[10:45:24 EDT(-0400)] <dstn> there is also another issue with IE7 and > 100% pushes the last column down
[10:45:29 EDT(-0400)] <athena> probably better to have it add up to 99 instead of 101
[10:45:32 EDT(-0400)] <athena> yeah, i'm not surprised
[10:45:41 EDT(-0400)] <athena> i don't think the old theme handled it very well either
[10:45:51 EDT(-0400)] <EricDalquist> dstn: yes I think we just got a report of that
[10:45:54 EDT(-0400)] <athena> although i can ask Fluid if that's something they'd consider a bug
[10:46:10 EDT(-0400)] <EricDalquist> even though our column widths == 100%
[10:46:17 EDT(-0400)] <EricDalquist> I'm wondering if it is some padding somewhere
[10:46:27 EDT(-0400)] <EricDalquist> and other than that have no clue what to do to fix it
[10:46:44 EDT(-0400)] <dstn> our fix, although not the greatest was to make it add up to < 100%
[10:47:02 EDT(-0400)] <dstn> with 3 columns, the space on the right isn't bad
[10:47:11 EDT(-0400)] <EricDalquist> hrm
[10:47:13 EDT(-0400)] <dstn> but the more columns, the worse it gets
[10:47:23 EDT(-0400)] <athena> hm, that doesn't sound right
[10:47:35 EDT(-0400)] <athena> you're seeing that happen even with the columns adding up to 100%?
[10:47:58 EDT(-0400)] <dstn> no, i'm saying based on our fix of making them add up to < 100%
[10:48:24 EDT(-0400)] <dstn> for instance, defining the 25 as 24% means its 4% off
[10:48:32 EDT(-0400)] <EricDalquist> athena: yes, we have 2 columns, 60% 40%
[10:48:41 EDT(-0400)] <athena> hm
[10:48:45 EDT(-0400)] <EricDalquist> and some users on IE7 see the column wrap if the browser window is too narrow
[10:48:45 EDT(-0400)] <dstn> but with lesser columns, the percent off is not as great
[10:48:51 EDT(-0400)] <athena> i'm pretty sure it doesn't do that in the default skin
[10:49:05 EDT(-0400)] <dstn> really? I thought it did
[10:49:21 EDT(-0400)] <dstn> off to file the widths issue
[10:49:21 EDT(-0400)] <dstn> brb
[10:55:41 EDT(-0400)] <dstn> Ok - http://www.ja-sig.org/issues/browse/UP-2433
[10:58:34 EDT(-0400)] <athena> thanks!
[11:00:41 EDT(-0400)] * fj4000 (n=Jacob@142.150.154.106) has joined ##uportal
[11:02:49 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[11:08:08 EDT(-0400)] * fj4000 (n=Jacob@142.150.154.106) has joined ##uportal
[11:16:57 EDT(-0400)] * fj4000 (n=Jacob@142.150.154.106) has joined ##uportal
[11:30:46 EDT(-0400)] * fj4000 (n=Jacob@142.150.154.106) has joined ##uportal
[11:39:15 EDT(-0400)] * holdorph (n=holdorph@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[12:03:46 EDT(-0400)] * jessm (n=Jess@c-71-232-1-65.hsd1.ma.comcast.net) has joined ##uportal
[12:19:47 EDT(-0400)] * awills (n=awills@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[12:27:26 EDT(-0400)] * bszabo_ (n=bszabo@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[12:45:29 EDT(-0400)] * fj4000 (n=Jacob@142.150.154.106) has joined ##uportal
[12:45:29 EDT(-0400)] * lennard1 (n=sparhk@ip68-98-56-21.ph.ph.cox.net) has joined ##uportal
[12:45:29 EDT(-0400)] * brad_laptop (n=bszabo@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[12:45:29 EDT(-0400)] * michelled (n=team@142.150.154.193) has joined ##uportal
[12:45:29 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[12:45:29 EDT(-0400)] * apetro- (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[12:45:29 EDT(-0400)] * Tuomaz (n=fredrik@ip223.taftea.se) has joined ##uportal
[12:46:25 EDT(-0400)] * monteslu (n=monteslu@ip68-109-171-127.ph.ph.cox.net) has joined ##uportal
[12:46:46 EDT(-0400)] * ChanServ (ChanServ@services.) has joined ##uportal
[12:46:46 EDT(-0400)] * athena (n=athena@99.129.100.66) has joined ##uportal
[12:46:46 EDT(-0400)] * dstn (n=dstn@unaffiliated/dstn) has joined ##uportal
[12:46:46 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[12:46:46 EDT(-0400)] * holdorph (n=holdorph@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[12:47:14 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[12:47:48 EDT(-0400)] * awills (n=awills@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[12:54:01 EDT(-0400)] * bszabo (n=bszabo@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[13:02:22 EDT(-0400)] * jessm (n=Jess@c-71-232-1-65.hsd1.ma.comcast.net) has joined ##uportal
[14:09:50 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[14:25:50 EDT(-0400)] <awills> hey folks...trying to wrap up UP-2174 (Support multiple user profiles in import/export tool), and I'd like to solicit some suggestions...
[14:25:57 EDT(-0400)]

<awills> for the command ">ant crn-expoprt -Dtype=profile -Dsysid=

Unknown macro: {username}

"...

[14:26:02 EDT(-0400)] <awills> should the output be 1 profile or all?
[14:33:07 EDT(-0400)] <athena> if it were one, how would we pick which profile to export?
[14:33:37 EDT(-0400)] <athena> does importing them actually work?
[14:34:23 EDT(-0400)] <awills> good question... what would be the result of always exporting profile 1 in that case?
[14:34:54 EDT(-0400)] <athena> it seems like in this case you really need two sysid identifiers
[14:35:16 EDT(-0400)] <awills> importing works, but it always imports to id=1 atm
[14:35:20 EDT(-0400)] <athena> one for the username, and one to be an identifier for the profile - either the name or whatever
[14:35:22 EDT(-0400)] <athena> ok
[14:35:30 EDT(-0400)] <athena> so it works for importing single profiles, but not multiple ones
[14:35:42 EDT(-0400)] <awills> that's right
[14:36:02 EDT(-0400)] <athena> gotcha
[14:36:05 EDT(-0400)] <awills> alternately, i could export all profiles for the specified user
[14:36:35 EDT(-0400)] <awills> i think it would work out, but would be slightly trickier for the portlet
[14:36:40 EDT(-0400)] <athena> that does seem like it's probably appropriate, without some sort of requested profile identifier
[14:36:51 EDT(-0400)] <athena> are they in different files?
[14:37:02 EDT(-0400)] <athena> maybe the portlet could output a batch file?
[14:37:11 EDT(-0400)] <awills> yeah, and I'd prefer not to introduce the complexity of another parameter
[14:37:16 EDT(-0400)] <athena> gotcha
[14:37:28 EDT(-0400)] <awills> yes, the portlet could do that... that's what i was thinking
[14:38:16 EDT(-0400)] <awills> for import, i'll have to change it to upsert on the profile name, which already exists and shouldn't be an issue
[14:38:59 EDT(-0400)] <athena> but if the relevant profiles don't exist (you're creating rather than updating), i suspect it wouldnt' work correctly
[14:39:08 EDT(-0400)] <athena> because the correct profile IDs wouldn't be assigned
[14:39:32 EDT(-0400)] <awills> ah... what works and doesn't when the user logs in is another matter

[14:39:41 EDT(-0400)] <athena> lol
[14:40:07 EDT(-0400)] <athena> well, perhaps it "works" if you define works to be "puts something in the database and claims success"

[14:40:09 EDT(-0400)] <awills> we know that code needs attention, if we're to support multiple profiles for real
[14:40:12 EDT(-0400)] <athena> yeah
[14:40:19 EDT(-0400)] <athena> someone really just needs to go in and make that not suck
[14:40:49 EDT(-0400)] <athena> probably just making the code do profile lookup by name rather than ID would be good enough to really actually fix this problem
[14:41:02 EDT(-0400)] <athena> it might not fix the issue with new users logging in who don't already have profiles
[14:41:14 EDT(-0400)] <athena> but i bet it would get the import really truly working (from the user's perspective)
[14:41:15 EDT(-0400)] <awills> yeah... but what it puts in the db needs to (1) work no worse than now w/ the code that's there, and (2) work appropriately with the needed fix once it's there
[14:41:24 EDT(-0400)] <athena> yeah
[14:41:26 EDT(-0400)] <athena> that's fair
[14:41:32 EDT(-0400)] <athena> and i think what you're proposing will do that
[14:41:37 EDT(-0400)] <awills> i do to
[14:42:00 EDT(-0400)] <athena> i do think the overall issue should get prioritized as a 3.2 fix
[14:42:08 EDT(-0400)] <awills> +1
[14:42:21 EDT(-0400)] <athena> we're getting to the point in the world where having a mobile theme would be really valuable and a good feature for uportal to be able to advertise
[14:42:26 EDT(-0400)] <awills> i'd like to see uP on modern phones asap
[14:42:34 EDT(-0400)] <athena> really we probably need this fix and at least one default mobile theme
[14:42:37 EDT(-0400)] <athena> me too
[14:42:58 EDT(-0400)] <awills> i'm on board... i'll do what I can to make it happen
[14:42:59 EDT(-0400)] <athena> i tried to convince yale to buy me an iphone a few years back so i could do iphone portal development, but that didn't really fly

[14:43:04 EDT(-0400)] <awills> and this is part of it

[14:43:13 EDT(-0400)] <athena> excellent
[14:43:28 EDT(-0400)] <athena> though ironically, i think there's real interest there from yale students: http://www.yaledailynews.com/articles/view/27336
[14:43:38 EDT(-0400)] <awills> i'm going to split for lunch, but will bb in a bit
[14:43:39 EDT(-0400)] <athena> they don't know they want a uportal mobile theme, but that's basically what they're asking for
[14:43:41 EDT(-0400)] <athena> cya!
[15:13:18 EDT(-0400)] * fj4000 (n=Jacob@142.150.154.106) has joined ##uportal
[15:20:38 EDT(-0400)] * lennard1 (n=sparhk@ip68-98-56-21.ph.ph.cox.net) has left ##uportal
[15:25:43 EDT(-0400)] * bszabo_ (n=bszabo@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[15:35:58 EDT(-0400)] * lennard1 (n=sparhk@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[15:50:20 EDT(-0400)] * EricDalquist (n=EricDalq@adsl-71-150-249-231.dsl.mdsnwi.sbcglobal.net) has joined ##uportal
[15:51:29 EDT(-0400)] <EricDalquist> quite the crowd today
[15:56:14 EDT(-0400)] * athena waves
[16:03:11 EDT(-0400)] <athena> EricDalquist: are there any existing SecurityContext implementations that make use of spring-configured resources?
[16:03:21 EDT(-0400)] <EricDalquist> I don't think so
[16:03:24 EDT(-0400)] <athena> ok
[16:03:46 EDT(-0400)] <athena> would doing that be just a matter of wiring up the right bean-finding tools, or is it likely to involve pain?
[16:05:00 EDT(-0400)] <EricDalquist> well the 'easy' way would be to use the portal app context locator
[16:05:12 EDT(-0400)] <EricDalquist> or mirror one of the existing Locator APIs that were added in 3.1 for legacy support
[16:05:32 EDT(-0400)] <EricDalquist> then the code just looks up the bean it needs each time it uses it
[16:05:54 EDT(-0400)] <athena> that sounds reasonable
[16:06:17 EDT(-0400)] <athena> and i'm sure we talked about this at some point before and i forgot
[16:06:24 EDT(-0400)] * tsnfoo (n=tsnfoo@wso-mbp15.test.denison.edu) has joined ##uportal
[16:06:25 EDT(-0400)] <EricDalquist> who knows

[16:06:28 EDT(-0400)] <athena> maybe

[16:06:31 EDT(-0400)] <EricDalquist> what version of uPortal are you working with?
[16:06:35 EDT(-0400)] <athena> some of this stuff i just dont' have to do very often
[16:06:36 EDT(-0400)] <athena> 3.1
[16:07:01 EDT(-0400)] <EricDalquist> look at the classes under org.jasig.portal.spring.locator
[16:07:07 EDT(-0400)] <EricDalquist> they were added in 3.1
[16:07:13 EDT(-0400)] <athena> considering writing a new SeucrityContext that would function like the existing CacheSecurityContext, but would encrypt the password before caching it
[16:07:16 EDT(-0400)] <athena> thanks, i'll try that
[16:07:20 EDT(-0400)] <EricDalquist> as a model of using spring configured resoures in non-spring managed code
[16:07:37 EDT(-0400)] <EricDalquist> while avoiding having to actually do a Map lookup every time you need the object reference
[16:07:39 EDT(-0400)] <athena> does that sound like something other people might potentially be interested in?
[16:07:48 EDT(-0400)] <athena> sounds great, thanks!
[16:07:54 EDT(-0400)] <EricDalquist> what are the requirements for that?
[16:08:10 EDT(-0400)] <EricDalquist> I mean the JVM would need to have the key in memory
[16:08:16 EDT(-0400)] <athena> yeah
[16:08:18 EDT(-0400)] <EricDalquist> unless you're thinking public/private key based encryption
[16:08:24 EDT(-0400)] <EricDalquist> and only the remote site has the private key
[16:57:49 EDT(-0400)] * apetro (n=apetro@98.174.242.39) has joined ##uportal
[17:07:00 EDT(-0400)] * fj4000 (n=Jacob@142.150.154.106) has joined ##uportal
[17:17:59 EDT(-0400)] <awills> Just posted a patch for exporting CBookmarks XBEL, if anyone's into that sort of thing: http://www.ja-sig.org/issues/browse/BOOKMARKS-21
[17:18:29 EDT(-0400)] <athena> woo!
[17:19:14 EDT(-0400)] <awills> yeah, don't know what precisely to do with it
[17:19:21 EDT(-0400)] <EricDalquist> so for static URL generation here is some info for what I have so far: http://uportal.pastebin.com/m69405520
[17:19:28 EDT(-0400)] <EricDalquist> that is where you get URL objects
[17:20:09 EDT(-0400)] <EricDalquist> I'm still trying to think of cases where a URL that is not targeting a specific channel/portlet needs to change the window
[17:20:12 EDT(-0400)] <EricDalquist> window state*
[17:20:22 EDT(-0400)] <awills> but after Yale I can say the CBookmarks --> PBookmarks migration is pretty well baked, if there's anyone who needs to do that
[17:20:29 EDT(-0400)] <EricDalquist> awills: great

[17:21:42 EDT(-0400)] <awills> anthony did a great job getting that started
[17:25:00 EDT(-0400)] <EricDalquist> so right now I think the following ways URLs that don't target a channel change the state are going from maximized to normal when clicking on a tab header or the uPortal logo
[17:26:45 EDT(-0400)] <awills> better URLs will be helpful, i hope it's going well
[17:27:05 EDT(-0400)] <EricDalquist> well its going

[17:27:14 EDT(-0400)] <EricDalquist> does that statement sound true?
[17:28:13 EDT(-0400)] <EricDalquist> the design idea so far is different URL objects for different actions
[17:28:47 EDT(-0400)] <EricDalquist> so to switch to a different tab you'd call "public ILayoutPortalUrl getFolderUrlByNodeId(HttpServletRequest request, String folderNodeId);"
[17:29:13 EDT(-0400)] <EricDalquist> which would then let you set parameters and toggle if the URL should reset to NORMAL state
[17:39:00 EDT(-0400)] <awills> sounds reasonable, and even familiar... do you know whether it's possible to have one getUrlByNodeId() method, and just "discover" if it's a folder/channel/whatever? would that be attractive if it is possible?
[17:39:19 EDT(-0400)] <EricDalquist> except the return type is different
[17:39:38 EDT(-0400)] <EricDalquist> you can set window state, portlet mode, portlet parameters, action/render on a portlet url
[17:39:55 EDT(-0400)] <EricDalquist> a layout url you just get portal parameters and a toggle to go back to NORMAL
[17:40:14 EDT(-0400)] <EricDalquist> so the code could figure out out
[17:40:39 EDT(-0400)] <EricDalquist> but the method return type wouldn't be able to tell what features of the URL you could use
[17:41:23 EDT(-0400)] <awills> sure, that makes sense
[17:41:43 EDT(-0400)] * apetro (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[17:41:52 EDT(-0400)] <EricDalquist> so that could exist and the return type could just be a IBasePortalUrl
[17:41:57 EDT(-0400)] <EricDalquist> where you can set portal scoped parameters
[17:44:00 EDT(-0400)] <awills> tough to say right now, but I could imagine a scenario where I'd be happy to have that... such as iterating over a collection of arbitrary layout nodes and getting a URL for each
[17:44:21 EDT(-0400)] <EricDalquist> right
[17:44:36 EDT(-0400)] <EricDalquist> my initial implementation of the API is only going to support linking to tabs or channels
[17:44:46 EDT(-0400)] <EricDalquist> but that will be a matter of one or two classes to 'fix'
[17:47:11 EDT(-0400)] <awills> sure
[18:53:45 EDT(-0400)] * tsnfoo (n=tsnfoo@cpe-173-88-45-236.columbus.res.rr.com) has joined ##uportal
[19:30:14 EDT(-0400)] * Sememmon (n=Sememmon@uni1.unicon.net) has joined ##uportal
[20:02:05 EDT(-0400)] * lennard1 (n=sparhk@wsip-98-174-242-39.ph.ph.cox.net) has left ##uportal
[20:09:24 EDT(-0400)] * EricDalquist (n=EricDalq@adsl-71-150-249-231.dsl.mdsnwi.sbcglobal.net) has joined ##uportal
[20:24:54 EDT(-0400)] * fj4000 (n=Jacob@142.150.154.106) has joined ##uportal
[20:57:09 EDT(-0400)] * EricDalquist (n=EricDalq@adsl-71-150-249-231.dsl.mdsnwi.sbcglobal.net) has joined ##uportal
[21:46:05 EDT(-0400)] * fj4000 (n=Jacob@142.150.154.106) has joined ##uportal
[23:08:16 EDT(-0400)] * EricDalquist (n=EricDalq@adsl-71-150-249-231.dsl.mdsnwi.sbcglobal.net) has joined ##uportal
[23:45:36 EDT(-0400)] * Sememmon (n=Sememmon@ip70-190-32-223.ph.ph.cox.net) has joined ##uportal

Browser not supported