Page Comparison

[08:20:32 EST(-0500)] * athena7 (n=athena7@adsl-99-130-147-23.dsl.wlfrct.sbcglobal.net) has joined ##uportal
[09:35:22 EST(-0500)] * colinclark (n=colin@bas1-toronto09-1279721821.dsl.bell.ca) has joined ##uportal
[09:56:11 EST(-0500)] * anastasiac (n=team@142.150.154.160) has joined ##uportal
[09:57:51 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[10:11:30 EST(-0500)] * anastasiac (n=team@142.150.154.160) has joined ##uportal
[10:11:30 EST(-0500)] * bulloche (n=bulloche@134.250.4.77) has joined ##uportal
[10:12:23 EST(-0500)] * colinclark (n=colin@bas1-toronto09-1279721821.dsl.bell.ca) has joined ##uportal
[10:21:11 EST(-0500)] * michelled (n=team@142.150.154.197) has joined ##uportal
[10:31:10 EST(-0500)] * holdorph (n=holdorph@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[10:34:15 EST(-0500)] <athena7> so EricDalquist, how goes up3?
[10:34:27 EST(-0500)] <athena7> it sounds like you guys upgraded?
[10:34:59 EST(-0500)] * colinclark (n=colin@bas1-toronto09-1279721821.dsl.bell.ca) has joined ##uportal
[10:34:59 EST(-0500)] * anastasiac (n=team@142.150.154.160) has joined ##uportal
[10:35:58 EST(-0500)] <EricDalquist> hey
[10:35:59 EST(-0500)] <EricDalquist> yeah
[10:36:07 EST(-0500)] <EricDalquist> upgrade went pretty well
[10:36:19 EST(-0500)] <EricDalquist> had a few bumps the day of
[10:36:23 EST(-0500)] <EricDalquist> but managed with no outage
[10:37:09 EST(-0500)] <EricDalquist> ran into this: https://issues.apache.org/jira/browse/DBCP-270 this weekend
[10:37:32 EST(-0500)] <EricDalquist> need to send out a warning on the user list for people currently on 3.0 since I think we have abandoned tracking enabled by default
[10:38:33 EST(-0500)] * lennard1 (n=sparhk@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[10:38:40 EST(-0500)] <athena7> ah
[10:38:41 EST(-0500)] <athena7> gotcha
[10:38:48 EST(-0500)] <athena7> glad it went well though
[10:38:55 EST(-0500)] <athena7> that's pretty cool for such a major upgrade
[10:40:51 EST(-0500)] <EricDalquist> yeah, I'm glad we're done with it{color}
[10:41:00 EST(-0500)] <EricDalquist> have a lot of post-upgrade cleanup still going on
[10:41:18 EST(-0500)] <EricDalquist> how was the vacation?
[10:41:29 EST(-0500)] <athena7> wonderful
[10:41:31 EST(-0500)] <athena7> ireland's beautiful
[10:42:06 EST(-0500)] <athena7> catching up on all the list e-mail from while i was gone - think i'm mostly through it now
[10:42:25 EST(-0500)] <EricDalquist>
[10:43:18 EST(-0500)] <athena7> there wasn't as much email as i expected
[10:43:41 EST(-0500)] <EricDalquist> yeah, lists have been pretty quiet
[10:43:43 EST(-0500)] <athena7> this is literally the longest i've gone without touching a computer keyboard since i don't know - junior high? no idea
[10:43:48 EST(-0500)] <EricDalquist> lol
[10:44:10 EST(-0500)] <athena7> yeah
[10:44:24 EST(-0500)] <athena7> kind of nice
[12:13:48 EST(-0500)] * apetro (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[13:19:48 EST(-0500)] * athena7 (n=athena7@adsl-99-130-147-23.dsl.wlfrct.sbcglobal.net) has joined ##uportal
[13:22:57 EST(-0500)] <athena7> unless anyone has objections, i'm going to tag the calendar portlet with a milestone today
[13:23:06 EST(-0500)] <athena7> so that we can start doing some of the proposed development
[13:23:15 EST(-0500)] <athena7> in particular, i'd love to integrate in the changes nick made
[13:41:35 EST(-0500)] * crille (n=crille@91-64-171-115-dynip.superkabel.de) has joined ##uportal
[13:42:01 EST(-0500)] * crille (n=crille@91-64-171-115-dynip.superkabel.de) has left ##uportal
[13:57:13 EST(-0500)] <EricDalquist> +1 athena7
[13:57:33 EST(-0500)] <athena7> ok
[13:57:39 EST(-0500)] <athena7> merging his changes in now
[13:57:47 EST(-0500)] <athena7> he did a great job, i'd love to see it all get into the project
[13:57:50 EST(-0500)] <athena7> robustness++
[14:21:34 EST(-0500)] <EricDalquist> so, I just found an issue with up3 and using portlets via FName
[14:22:02 EST(-0500)] <EricDalquist> currently the portlet persistence part of the framework has no concept of transient subscribe IDs
[14:22:21 EST(-0500)] <EricDalquist> which is a problem because you end up with a subscribe ID of something like 'ctf1' written to the database
[14:22:37 EST(-0500)] <EricDalquist> and then on later uses of the portal you can get the wrong portlet if you happen to use a different portlet first
[14:22:40 EST(-0500)] <athena7> up 3.1?
[14:22:51 EST(-0500)] <EricDalquist> I think this would happen in 3.0 too
[14:22:54 EST(-0500)] <athena7> ick
[14:23:03 EST(-0500)] <EricDalquist> I think I can fix it without too much trouble
[14:23:08 EST(-0500)] <athena7> that's good
[14:23:10 EST(-0500)] <EricDalquist> I'm just trying to figure out the appropriate behavior
[14:23:20 EST(-0500)] <athena7> it'd be kidn of nice to get yale's guest fname mofidications in
[14:23:24 EST(-0500)] <EricDalquist> primarily, should portlet preferences for a transient portlet get stored?
[14:23:49 EST(-0500)] <EricDalquist> prefs that a portlet sets at runtime are stored on the entity
[14:24:10 EST(-0500)] <EricDalquist> and the entity is keyed off userId, portletDefId and subscribeId
[14:24:41 EST(-0500)] <EricDalquist> so if we want those to persist I need to translate 'ctf1' into a value that is actually unique for that portlet definition
[14:24:49 EST(-0500)] <EricDalquist> right now my two thoughts are:
[14:25:18 EST(-0500)] <athena7> hm
[14:25:23 EST(-0500)] <EricDalquist> 1. munge the subscribe ID in the database as 'ctf.[chanDefId]'
[14:25:37 EST(-0500)] <EricDalquist> 2. don't store database persistent entities for transient portlets
[14:26:15 EST(-0500)] <athena7> i guess the use case for the first might be a portlet that's linked to somewhere, maybe used frequently, but isn't part of the user layout?
[14:26:19 EST(-0500)] <EricDalquist> 1. would result in a portlet accessed by fname having its own set of prefs, used any time that portlet is called via fname and not already in the user's layout
[14:26:24 EST(-0500)] <EricDalquist> yes
[14:26:36 EST(-0500)] <EricDalquist> 2. would result in prefs just disappearing between sessions
[14:26:57 EST(-0500)] <athena7> a little confusing for 1 since if the user then clicks on "add to my layout" they'd lose any preferences they'd set, i guess
[14:27:04 EST(-0500)] <EricDalquist> yup
[14:27:12 EST(-0500)] <EricDalquist> unless logic was added to clone the data
[14:27:20 EST(-0500)] <athena7> but i can see how people might want that feature at times
[14:27:21 EST(-0500)] <EricDalquist> which should be doable
[14:29:36 EST(-0500)] <EricDalquist> so you're leaning towards 1?
[14:29:43 EST(-0500)] <athena7> i guess so
[14:29:51 EST(-0500)] <athena7> i really hadn't thought about that until you mentioned it
[14:29:58 EST(-0500)] <athena7> i'm not sure - i haven't ever really had that need
[14:30:00 EST(-0500)] <athena7> but it's plausible
[14:30:10 EST(-0500)] <athena7> i mean i guess we could ask other people and see what their expectations would be?
[14:30:22 EST(-0500)] <EricDalquist> yeah
[14:31:18 EST(-0500)] <EricDalquist> brb
[14:42:47 EST(-0500)] <athena7> so what's the status on the javascript stuff that was discussed at the unconference?
[14:43:09 EST(-0500)] <EricDalquist> the dynamic building of it?
[14:43:17 EST(-0500)] <EricDalquist> nothing has happened as far as I know
[14:43:27 EST(-0500)] <holdorph> I find "1" troubling, based on the words you used above. So either I'm misunderstanding, or maybe there is a slght change to it. but you say "if the portlet is not already in their layout"
[14:43:41 EST(-0500)] <holdorph> would that mean users would get different behavior if it was or was not in their layout?
[14:43:53 EST(-0500)] <holdorph> that seems like a system admin/customer support nightmare
[14:44:16 EST(-0500)] <athena7> do we at least have a ticket encapsulating the conference discussion?
[14:44:49 EST(-0500)] <EricDalquist> athena7: I don't think so :/
[14:44:53 EST(-0500)] <athena7> normally preferences get saved for a portlet, and saved to the portlet's subscribe id
[14:45:03 EST(-0500)] <EricDalquist> holdorph: the 'if it isn't in their layout' is already part of the portal's behavior for fname links
[14:45:13 EST(-0500)] <athena7> but what happens if the portlet isn't in their layout? if they call up the portlet again, do they get back any preferences they set last time?
[14:45:20 EST(-0500)] <athena7> or do they just magically disappear?
[14:45:46 EST(-0500)] <EricDalquist> if you do an fname link the behavior is to first to a XPath search the user's layout for the channel, if it exists the first subscribe ID found is used for interacting with the channel
[14:45:59 EST(-0500)] <EricDalquist> if it isn't found a transient subscribe ID is generated and used
[14:46:35 EST(-0500)] <EricDalquist> the transient layout manager exposes a constant channels can use for checking if their subscribe ID is transient or not
[14:46:43 EST(-0500)] <holdorph> ok, that makes sense, sounds like a better plan, i vote for "1", with an additional jira item to do the cloning, being a 'nice to have'
[14:47:22 EST(-0500)] <EricDalquist> I'm scratching out how I'm going to fix this and I may see if it is feasible to have a config option to toggle the behavior
[14:47:39 EST(-0500)] <EricDalquist> we'll see how much complexity that adds though
[14:48:20 EST(-0500)] <holdorph> a more general version of the toggle, seems there might be places where it would be nice to have a uportal level override, to not allow storing of portlet preferences period.
[14:48:40 EST(-0500)] <holdorph> er, personal saved versions of them anyway
[14:49:25 EST(-0500)] <EricDalquist> what would a use-case for that be?
[14:49:27 EST(-0500)] <holdorph> i know you can make them read-only, which is one approach, but it might be nice to either expose that read-only part in channel manager, or... something along those lines anyway, so you didn't have to edit portlet.xml
[14:49:37 EST(-0500)] <EricDalquist> ah
[14:49:52 EST(-0500)] <EricDalquist> 3.1 has a better portlet prefs UI in channel manager
[14:49:57 EST(-0500)] <EricDalquist> that would let you do that
[14:50:11 EST(-0500)] <EricDalquist> you'd have to re-enter the prefs, but you could mark them readOnly when doing so
[14:50:29 EST(-0500)] <EricDalquist> that could/would cause the portlet to simply fail though most likely
[14:50:42 EST(-0500)] <EricDalquist> unless it was designed to handle the exception that is thrown when you modify a readOny pref
[14:50:45 EST(-0500)] <holdorph> right, so, what about a simpler option, that gives an admin the ability to just 'set all perfs readonly'
[14:51:24 EST(-0500)] <EricDalquist> yeah, it would be doable, I guess I just don't see a use-case
[14:51:35 EST(-0500)] <EricDalquist> the portlet would have to be coded to handle not being able to write to prefs
[14:51:48 EST(-0500)] <holdorph> some people build portals that are not very-user-customizable
[14:51:53 EST(-0500)] <holdorph> why, i dont know, but it is common
[14:52:07 EST(-0500)] <EricDalquist> in which case just adding the desired functionality into the portlet would seem better
[14:52:11 EST(-0500)] <holdorph> having the ability to further disallow customization would be useful to these people
[14:52:19 EST(-0500)] <EricDalquist> yeah, I see that
[14:52:27 EST(-0500)] <holdorph> what about portlets you're pulling 'off the shelf' you didn't write
[14:52:45 EST(-0500)] <EricDalquist> but most portlets don't handle having preferences they expect to be able to write to marked read-only very well
[14:52:58 EST(-0500)] <EricDalquist> unless you have more of a 'write to /dev/null' behavior
[14:53:06 EST(-0500)] <EricDalquist> where writes are just silently ignorec
[14:53:30 EST(-0500)] <holdorph> well when they encounter that the portlet doesn't work very well, it would be in their power to turn it back on
[14:53:36 EST(-0500)] <holdorph> or to re-write the portlet
[14:53:50 EST(-0500)] <EricDalquist> true
[14:53:55 EST(-0500)] <EricDalquist> so back to the pressing issue ....
[14:54:03 EST(-0500)] <EricDalquist> handling preferences for transient portlets