uPortal IRC Logs-2009-05-15

Owned by Apereo Infrastructure
Last updated: May 15, 2009Version comment

[03:54:52 EDT(-0400)] * higmad (n=chatzill@pcit-8752.hig.se) has joined ##uportal
[07:12:09 EDT(-0400)] * tsnfoo (n=tsnfoo@cpe-173-88-27-191.columbus.res.rr.com) has joined ##uportal
[08:12:54 EDT(-0400)] * michelled (n=michelle@CPE001310472ade-CM0011aefd3ca8.cpe.net.cable.rogers.com) has joined ##uportal
[08:25:04 EDT(-0400)] * athena (n=athena@99.129.100.66) has joined ##uportal
[08:29:37 EDT(-0400)] * michelled_ (n=michelle@CPE001310472ade-CM0011aefd3ca8.cpe.net.cable.rogers.com) has joined ##uportal
[08:53:56 EDT(-0400)] * colinclark (n=colin@bas2-toronto09-1176131435.dsl.bell.ca) has joined ##uportal
[08:55:43 EDT(-0400)] * tsnfoo (n=tsnfoo@wso-mbp15.test.denison.edu) has joined ##uportal
[09:00:16 EDT(-0400)] * fj4000 (n=Main@CPE0018f85ab63e-CM001692f5798c.cpe.net.cable.rogers.com) has joined ##uportal
[09:19:51 EDT(-0400)] * Sememmon (n=Sememmon@ip70-190-32-223.ph.ph.cox.net) has joined ##uportal
[10:30:36 EDT(-0400)] * lennard1 (n=sparhk@uni1.unicon.net) has joined ##uportal
[10:48:00 EDT(-0400)] * apetro (n=apetro@ip68-3-207-51.ph.ph.cox.net) has joined ##uportal
[11:01:12 EDT(-0400)] * EricDalquist (n=EricDalq@static-210-59.vpn.wisc.edu) has joined ##uportal
[11:27:35 EDT(-0400)] * holdorph (n=holdorph@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[11:53:07 EDT(-0400)] * jessm (n=Jess@c-71-232-1-65.hsd1.ma.comcast.net) has joined ##uportal
[12:04:57 EDT(-0400)] * apetro (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[12:07:27 EDT(-0400)] <athena> i'm still getting occasionally errrors like
[12:07:28 EDT(-0400)] <athena> java.lang.IllegalStateException: An existing HttpSession is required while retrieving a UserInstance for a HttpServletRequest
[12:07:40 EDT(-0400)] <EricDalquist> does it happen when there is a timeout?
[12:07:57 EDT(-0400)] <athena> hm, it might
[12:08:10 EDT(-0400)] <athena> would that cause it?
[12:08:28 EDT(-0400)] <EricDalquist> yes
[12:08:42 EDT(-0400)] <athena> ok, i'll look out for that then
[12:08:43 EDT(-0400)] <EricDalquist> Tomcat provides webapps with a shell of a request objet
[12:09:00 EDT(-0400)] <EricDalquist> when the webapp is done with the request the shell is cleared out and disposed of
[12:09:13 EDT(-0400)] <EricDalquist> so things like session access and such end up returning null
[12:09:31 EDT(-0400)] <EricDalquist> we could/should add our own wrapper in channel rendering that would provide a better error message
[12:09:45 EDT(-0400)] <athena> gotcha
[12:15:11 EDT(-0400)] <athena> just let me know when you have time for a few channel manager questions?
[12:15:30 EDT(-0400)] <EricDalquist> will do
[12:15:38 EDT(-0400)] <EricDalquist> it will be about an hour from now I hope
[12:17:17 EDT(-0400)] <athena> sure
[12:17:28 EDT(-0400)] <athena> trying to track down a few bugs in the meantime
[12:17:33 EDT(-0400)] <EricDalquist> k
[12:17:50 EDT(-0400)] <athena> found a few pieces that needed fixing from last night's commit
[12:50:35 EDT(-0400)] * Sememmon (n=Sememmon@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[13:20:07 EDT(-0400)] <EricDalquist> ok athena
[13:20:09 EDT(-0400)] <EricDalquist> whats up
[13:20:27 EDT(-0400)] <athena> so first of all, does the current CChannelManager implementation support multi-valued portlet preferences?
[13:20:35 EDT(-0400)] <athena> i couldn't figure out how to set them as such in the user interface
[13:20:54 EDT(-0400)] <EricDalquist> I think it does
[13:20:59 EDT(-0400)] <EricDalquist> there is a checkbox in the UI
[13:21:06 EDT(-0400)] <EricDalquist> that says something like add or overwrite
[13:21:39 EDT(-0400)] <athena> hm, ok, i'll look at it again
[13:22:00 EDT(-0400)] <athena> the other thing i wasn't sure about was how much is coming from the CPD and how much is hard-coding somewhere
[13:22:32 EDT(-0400)] <athena> what does it do? does it just look for the "PORTLET." prefix on incoming parameters and assign those as preferences?
[13:22:52 EDT(-0400)] <athena> or is the XSL wired to do something different for portlets?
[13:23:06 EDT(-0400)] <EricDalquist> it does the PORTLET. check
[13:23:20 EDT(-0400)] <athena> so do regular channel parameters support multiple values?
[13:23:23 EDT(-0400)] <EricDalquist> the better option would be to extend the CPD format to support prefs like the 3.1 .channel files
[13:23:26 EDT(-0400)] <EricDalquist> no
[13:23:27 EDT(-0400)] <EricDalquist> they do not
[13:23:39 EDT(-0400)] <EricDalquist> which means you can only add single valued prefs via CPDs right now
[13:23:46 EDT(-0400)] <athena> ok
[13:24:03 EDT(-0400)] <athena> is the XSL hard-coded to allow "PORTLET." prefs to be treated as multi-valued in the user interface?
[13:24:41 EDT(-0400)] <EricDalquist> no, the multi-valued UI is a whole new screen just for portlets
[13:24:50 EDT(-0400)] <athena> ok
[13:25:26 EDT(-0400)] <athena> so it looks for the "PORTLET." arbitrary parameters step and inserts that screen instead of doing the normal arbitrary parameters thing?
[13:25:50 EDT(-0400)] * michelled (n=michelle@CPE001310472ade-CM0011aefd3ca8.cpe.net.cable.rogers.com) has joined ##uportal
[13:25:52 EDT(-0400)] <EricDalquist> no
[13:26:07 EDT(-0400)] <EricDalquist> so there is no support for multivalued prefs coming from PORTLET. CPD parameters
[13:26:28 EDT(-0400)] <EricDalquist> the only new thing is a new screen that is displayed for portlet types that gives you a generic edit portlet prefs UI
[13:26:45 EDT(-0400)] <EricDalquist> if you write a CPD that prompts the user for a PORTLET. value no multi-valued support exists
[13:27:19 EDT(-0400)] <athena> ok . . . i'm not sure i'm totally following
[13:27:35 EDT(-0400)] <athena> the current CSpringPortletAdaptor CPD defines a PORTLET. arbitrary parameters section
[13:27:40 EDT(-0400)] <athena> does that mean we should remove that section?
[13:28:01 EDT(-0400)] <EricDalquist> um
[13:28:06 EDT(-0400)] <EricDalquist> I think I need to go look at the code
[13:28:37 EDT(-0400)] <athena> sorry!
[13:28:48 EDT(-0400)] <athena> i just want to make sure the new portlet winds up doing the right thing
[13:29:14 EDT(-0400)] <EricDalquist> well here I think we can define what the right thing is
[13:29:25 EDT(-0400)] <EricDalquist> there is no reason we have to copy exactly what 3.1 did
[13:29:52 EDT(-0400)] <athena> yeah, especially if we're getting rid of the CChannelManager channel
[13:30:05 EDT(-0400)] <EricDalquist> what would be useful would be a generic portlet prefs edit screen and the ability for a CPD to prompt the user for portlet preference values or just specify portlet prefs
[13:30:35 EDT(-0400)] <EricDalquist> the hardest part is getting a decent UI that lets the user specify any number of names and any number of values per name
[13:30:41 EDT(-0400)] <EricDalquist> at least that was the hardest for me
[13:31:07 EDT(-0400)] <athena> so sort of the parallel equivalent of specific parameters with default values and arbitrary preferences?
[13:31:19 EDT(-0400)] <athena> so that you can decide whether a portlet should be able to have arbitrary preferences?
[13:31:34 EDT(-0400)] * michelled_ (n=michelle@CPE001310472ade-CM0011aefd3ca8.cpe.net.cable.rogers.com) has joined ##uportal
[13:31:35 EDT(-0400)] <athena> yeah that's hard for me too - but luckily Gary's on this project, so i can defer to his expertise (smile)
[13:31:48 EDT(-0400)] <EricDalquist> yeah
[13:32:05 EDT(-0400)] <EricDalquist> so the chan parameters support is decent
[13:32:17 EDT(-0400)] <EricDalquist> you can have the user edit arbitrary params or specify some or prompt for some
[13:32:28 EDT(-0400)] <EricDalquist> having that AND the same set of UIs for portlet prefs would be great
[13:32:45 EDT(-0400)] <athena> so
[13:32:53 EDT(-0400)] <EricDalquist> the only other feature I added in 3.1 was in the arbitrary edit of portlet prefs UI you can see all the portlet prefs defined in portlet.xml
[13:32:58 EDT(-0400)] <athena> maybe just double the parameters suport in the cpd
[13:33:07 EDT(-0400)] <athena> yeah i noticed that - seems nice (smile)
[13:33:17 EDT(-0400)] <athena> do portlet definition preferences override those?
[13:33:23 EDT(-0400)] <EricDalquist> yes
[13:33:26 EDT(-0400)] <athena> ok
[13:33:30 EDT(-0400)] <EricDalquist> yeah, we probably want to create some new elements like was done in the .channel files
[13:33:33 EDT(-0400)] <athena> and then you can decide whether they should be user-editable
[13:33:41 EDT(-0400)] <athena> sounds good
[13:33:48 EDT(-0400)] <athena> i think i could do that today
[13:33:54 EDT(-0400)] <EricDalquist> awesome
[13:33:59 EDT(-0400)] <EricDalquist> I started looking at the changes last night
[13:34:08 EDT(-0400)] <EricDalquist> I have some tweaks I'll run by you later today
[13:34:14 EDT(-0400)] <athena> oh that sound sgreat
[13:35:06 EDT(-0400)] <athena> i'm sure there's some things that need to be cleaned up
[13:35:07 EDT(-0400)] <EricDalquist> one feature we're going to have to get rid of is the <id> element in .channel files
[13:35:14 EDT(-0400)] <athena> and we need to add some caching too
[13:35:26 EDT(-0400)] <EricDalquist> that will cause serious problems if we aren't using the hibernate sequence generate to get all channel def ID values
[13:35:38 EDT(-0400)] <athena> i didn't think there even was an <id> element?
[13:36:36 EDT(-0400)] <athena> right now i'm playing with switching the ChannelPublisher over to use the new ChannelPublishingService so that we're not replicating code all over the place
[13:36:37 EDT(-0400)] <EricDalquist> yes
[13:36:50 EDT(-0400)] <EricDalquist> if you specify an <id> in a .channel file it will set the ID to that value
[13:36:53 EDT(-0400)] <EricDalquist> rather dangerous
[13:36:53 EDT(-0400)] <athena> i don't see it in any of the files i have - is that an optional element or something?
[13:36:54 EDT(-0400)] <athena> ohhh
[13:36:56 EDT(-0400)] <athena> eep
[13:37:04 EDT(-0400)] <athena> i didn't even realize you could do that
[13:37:09 EDT(-0400)] <EricDalquist> yeah
[13:37:27 EDT(-0400)] <EricDalquist> that is what they channel registry aPI to create a channel def with an id exists
[13:37:31 EDT(-0400)] <EricDalquist> that API has to be deleted
[13:37:34 EDT(-0400)] <athena> yeah
[13:37:38 EDT(-0400)] <EricDalquist> but that is one of the things I'm looking at
[13:37:43 EDT(-0400)] <athena> i was thinking we probably needed to get rid of that
[13:38:01 EDT(-0400)] <athena> it also looks like we may need to switch the approver and publisher ids over to Longs
[13:38:08 EDT(-0400)] <athena> either that or set the default value to -1
[13:38:21 EDT(-0400)] <athena> right now they're getting auto-created as 0s, which overlaps with the system id
[13:38:27 EDT(-0400)] <EricDalquist> ah
[13:38:28 EDT(-0400)] <EricDalquist> yeah
[13:38:35 EDT(-0400)] <EricDalquist> defaulting them to -1 is recommended for hibernate
[13:38:41 EDT(-0400)] <athena> ok, sounds good
[13:39:01 EDT(-0400)] <athena> i'd set the main IDs to longs so that they could internally be null
[13:39:22 EDT(-0400)] <athena> the ChannelType is particularly weird for IDs, because for that one, -1 actually means Custom channel
[13:39:52 EDT(-0400)] <athena> but that's something else we probably want to get rid of, as we talked about yesterday
[13:40:01 EDT(-0400)] <EricDalquist> yeah
[13:40:09 EDT(-0400)] <EricDalquist> we need to create a real custom type
[13:41:22 EDT(-0400)] <athena> yeah
[13:41:27 EDT(-0400)] <athena> well, we already have the CPD
[13:41:41 EDT(-0400)] <athena> so i can create a .channel-type file for it
[13:42:02 EDT(-0400)] <athena> i suppose it won't kill anything for the custom type to show up twice in CChannelManager until we delete that channel
[13:42:06 EDT(-0400)] <EricDalquist> ah
[13:42:07 EDT(-0400)] <EricDalquist> nope
[13:42:48 EDT(-0400)] <athena> ok, that's no problem - can do
[13:43:07 EDT(-0400)] <athena> once that's done we can actually create a hibernate association between the channel and channeltype classes too, if we want
[13:44:51 EDT(-0400)] <EricDalquist> sounds good
[13:45:27 EDT(-0400)] <athena> looks like the ChannelPublisher refactoring works
[13:45:38 EDT(-0400)] <EricDalquist> great
[13:45:43 EDT(-0400)] <athena> so once i check that in, that'll be one less place channel-publishing logic exists
[13:46:08 EDT(-0400)] <EricDalquist> (smile)
[13:49:06 EDT(-0400)] <athena> what should the type for the custom channel be?
[13:49:43 EDT(-0400)] <EricDalquist> Hrm
[13:50:18 EDT(-0400)] <athena> it seems like in general it's a java class, though in this case the user specifies it
[13:50:26 EDT(-0400)] <athena> is there maybe a channel interface that would be appropriate to use?
[13:50:47 EDT(-0400)] <EricDalquist> yeah
[13:50:47 EDT(-0400)] <athena> like IChannel or something?
[13:50:55 EDT(-0400)] <EricDalquist> lets give that a try
[13:51:01 EDT(-0400)] <athena> ok
[13:51:02 EDT(-0400)] <athena> will do
[13:57:22 EDT(-0400)] * tsnfoo (n=tsnfoo@cpe-173-88-27-191.columbus.res.rr.com) has joined ##uportal
[14:03:49 EDT(-0400)] <athena> does it actually make sense to have multiple arbitrary parameter sections defined in a CPD?
[14:04:34 EDT(-0400)] <EricDalquist> like multiple times a user could enter arbitrary channel parameters?
[14:06:03 EDT(-0400)] <athena> the CPD defines "arbitrary-preferences*"
[14:06:15 EDT(-0400)] <athena> so you could potentially have multiple sections, each with its own prefix
[14:06:34 EDT(-0400)] <EricDalquist> what does the prefix do?
[14:07:14 EDT(-0400)] <athena> that's the thing that makes the preference look like
[14:07:17 EDT(-0400)] <athena> APPLET.name
[14:07:31 EDT(-0400)] <EricDalquist> ah
[14:07:40 EDT(-0400)] <EricDalquist> so what is the use of the prefix?
[14:07:45 EDT(-0400)] <EricDalquist> for preferences
[14:08:04 EDT(-0400)] <EricDalquist> so right now the CPDs have <arbitrary-parameters>
[14:08:19 EDT(-0400)] <EricDalquist> we;re talking about the new arbitrary-preferences?
[14:08:25 EDT(-0400)] <EricDalquist> I guess it could
[14:08:29 EDT(-0400)] <EricDalquist> wouldn't really hurt
[14:09:34 EDT(-0400)] <athena> well, actually i was asking about the <arbitrary-parameter>
[14:09:55 EDT(-0400)] <athena> there almost definitely isn't a reason to supply multiple portlet preference sections
[14:10:03 EDT(-0400)] <EricDalquist> ah
[14:10:11 EDT(-0400)] <EricDalquist> well some CPDs currently use that I think
[14:10:15 EDT(-0400)] <athena> yeah
[14:10:26 EDT(-0400)] <athena> i really don't know why, but i've tried to support it in case someone was using it
[14:10:29 EDT(-0400)] <athena> it's kind of a pain though
[14:10:33 EDT(-0400)] <EricDalquist> hrm
[14:10:50 EDT(-0400)] <EricDalquist> my vote would be to take the easy way and leave it out for now
[14:11:04 EDT(-0400)] <athena> for the preference or for both?
[14:11:37 EDT(-0400)] <EricDalquist> well ...
[14:11:52 EDT(-0400)] <EricDalquist> it seems semi-interesting
[14:11:59 EDT(-0400)] <EricDalquist> but not enough for either to spend a lot of time dealing with right now
[14:13:20 EDT(-0400)] <athena> yeah
[14:14:01 EDT(-0400)] * lennard1 (n=sparhk@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[14:37:09 EDT(-0400)] <athena> EricDalquist: is there anything else that was added to CChannelManager as of 3.1 that we haven't talked about?
[14:37:23 EDT(-0400)] <EricDalquist> I don't think so
[14:37:37 EDT(-0400)] <athena> ok
[14:38:03 EDT(-0400)] <athena> i'm hoping that once i update the CPD and add support for portlet preferences we'll be caught up to CChannelManager
[14:38:20 EDT(-0400)] <athena> and new portlet will handle all expected portlet operations as well or better than the old version
[14:38:44 EDT(-0400)] <athena> at some point we may want to change the link to the portlet manager to point to the new version to help test it
[14:38:45 EDT(-0400)] <EricDalquist> great
[14:41:29 EDT(-0400)] <EricDalquist> brb
[14:43:51 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[14:53:36 EDT(-0400)] <athena> hm.
[14:53:59 EDT(-0400)] <athena> i'm wondering what we want to do about the portlet preferences in terms of the UI
[14:54:19 EDT(-0400)] <athena> like channel parameters have all sorts of options - specify the UI control, possible values, etc.
[14:55:00 EDT(-0400)] <athena> i don't know if we want to do the same thing for portlet preferences, and if so, how that interacts with multiple values
[14:55:39 EDT(-0400)] <athena> maybe we add some sort of "allowMultiple" property to the parameter type
[14:56:20 EDT(-0400)] <athena> and then define behavior for different UI types - like for a select menu we just use a multi-select, and for a regular text input we let the user add more fields
[15:19:27 EDT(-0400)] <athena> EricDalquist: so, oddly enough, the cpd dtd does define "multi-choice" as an allowable input type
[15:19:35 EDT(-0400)] <athena> was there once support for multi-valued channel params?
[15:19:40 EDT(-0400)] <EricDalquist> no
[15:19:50 EDT(-0400)] <EricDalquist> that is for a different ui item
[15:20:00 EDT(-0400)] <EricDalquist> but still only signle valued I think
[15:21:24 EDT(-0400)] <athena> hm - it does seem to display a <select multiple="multiple">
[15:21:30 EDT(-0400)] <athena> we just don't have any CPDs that use it
[15:21:34 EDT(-0400)] <EricDalquist> weird
[15:21:37 EDT(-0400)] <athena> yeah
[15:21:39 EDT(-0400)] <EricDalquist> the data model definetly does not support it
[15:22:31 EDT(-0400)] <athena> yeah
[15:22:35 EDT(-0400)] <athena> i was surprised to see it
[15:23:09 EDT(-0400)] <athena> basically you pick whether it's multi-choice, single-choice, or text
[15:23:23 EDT(-0400)] <athena> and once that's picked, things like select and checkbox display options are rendered differently
[15:23:34 EDT(-0400)] <athena> though presumably some of those combinations don't make sense
[15:23:45 EDT(-0400)] <athena> shoot foot here, and all
[15:29:15 EDT(-0400)] * lennard1 (n=sparhk@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[15:29:22 EDT(-0400)] <EricDalquist> yup
[16:01:26 EDT(-0400)] <athena> i don't understand why you can specify default values in both the parameter and the restriction
[16:01:37 EDT(-0400)] <EricDalquist> um
[16:01:40 EDT(-0400)] <EricDalquist> that is weird
[16:02:27 EDT(-0400)] <athena> yeah
[16:02:41 EDT(-0400)] <athena> the XSL checks for a default first in the parameter, then again in the restriction
[16:03:31 EDT(-0400)] * holdorph (n=holdorph@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[16:03:36 EDT(-0400)] <athena> can't really think of a reason why you'd need it in one place versus the other
[16:03:40 EDT(-0400)] <athena> i really hate this CPD
[16:03:56 EDT(-0400)] <athena> it's like codifying randomness (smile)
[16:04:10 EDT(-0400)] <EricDalquist> lol
[16:04:25 EDT(-0400)] <athena> this makes no sense but at least we wrote it down and made it official!!
[16:04:43 EDT(-0400)] <athena> no i assume some of it made sense at the time and it just hasn't evolved w/ the rest of the portal
[16:04:53 EDT(-0400)] <EricDalquist> yeah
[16:27:46 EDT(-0400)] * Sememmon (n=Sememmon@uni1.unicon.net) has joined ##uportal
[16:44:25 EDT(-0400)] <athena> hm, i guess we need to add some methods to the IChannelDefinition interface for adding portlet preferences
[16:44:49 EDT(-0400)] <EricDalquist> why there?
[16:49:15 EDT(-0400)] <athena> so we can add new portlet preferences
[16:49:31 EDT(-0400)] <EricDalquist> does the flow use the IChannelDefinition as the model?
[16:49:39 EDT(-0400)] <athena> no, it uses a separate form
[16:49:57 EDT(-0400)] <EricDalquist> so the current channel manager code looks up the portlet definition
[16:50:00 EDT(-0400)] <EricDalquist> and adds them there
[16:50:07 EDT(-0400)] <EricDalquist> which is where they are stored in the db
[16:50:40 EDT(-0400)] <athena> right but i mean i can't update them on the channel definition before that IChannelDefinition is handed off to the IChannelRegistryStore
[16:51:18 EDT(-0400)] <EricDalquist> I'm not sure I follow
[16:51:39 EDT(-0400)] <athena> let me double check something
[16:52:57 EDT(-0400)] <athena> trying to find the old RDBMChannelRegistryStore
[16:54:25 EDT(-0400)] <EricDalquist> ah yeah
[16:54:27 EDT(-0400)] <EricDalquist> I see
[16:54:37 EDT(-0400)] <EricDalquist> the old code has a private field in ChannelDefinition: private Map<String, IPortletPreference> portletPreferences;
[16:54:40 EDT(-0400)] <athena> yeah
[16:54:59 EDT(-0400)] <athena> and i think the channel service code was the part responsible for persisting those preferences
[16:55:20 EDT(-0400)] <athena> i think it called the portlet API logic from the saveChannelDefinition method of RDBMChannelRegistryStore
[16:55:37 EDT(-0400)] <EricDalquist> if (isPortlet) {
[16:55:37 EDT(-0400)] <EricDalquist> //Get or Create the portlet definition
[16:55:37 EDT(-0400)] <EricDalquist> final IPortletDefinition portletDefinition = this.portletDefinitionRegistry.getOrCreatePortletDefinition(channelPublishId);
[16:55:37 EDT(-0400)] <EricDalquist>
[16:55:37 EDT(-0400)] <EricDalquist> //Update the preferences of the portlet definition
[16:55:39 EDT(-0400)] <EricDalquist> final IPortletPreferences portletPreferences = portletDefinition.getPortletPreferences();
[16:55:42 EDT(-0400)] <EricDalquist> portletPreferences.setPortletPreferences(Arrays.asList(channelDef.getPortletPreferences()));
[16:55:42 EDT(-0400)] <athena> yeah
[16:55:45 EDT(-0400)] <EricDalquist> this.portletDefinitionRegistry.updatePortletDefinition(portletDefinition);
[16:55:47 EDT(-0400)] <EricDalquist> }
[16:55:49 EDT(-0400)] <EricDalquist> yup
[16:55:51 EDT(-0400)] <EricDalquist> so this can get solved when we add the relationships too
[16:55:55 EDT(-0400)] <athena> right
[16:56:15 EDT(-0400)] <athena> but for it to be persisting the right portlet preferences, we have to have a way to actually updated them
[16:56:19 EDT(-0400)] <EricDalquist> since once we get that working we should have a IChannelDefinition.getPortletDefinition()
[16:56:28 EDT(-0400)] <EricDalquist> that would return null for anything that isn't a portlet
[16:56:31 EDT(-0400)] <athena> ok
[16:57:05 EDT(-0400)] <athena> so until that work gets done i think i'm going to need to add a setPreferences() method
[16:57:11 EDT(-0400)] <EricDalquist> yeah
[17:00:36 EDT(-0400)] <athena> oh here we go
[17:00:45 EDT(-0400)] <athena> replacePortletPreferences
[17:01:09 EDT(-0400)] <athena> that should do it
[17:01:17 EDT(-0400)] <EricDalquist> yup
[17:01:45 EDT(-0400)] <EricDalquist> oh so my first pass at the changes you've made so far was to make the new JPA persisted impl classes package private
[17:01:55 EDT(-0400)] <EricDalquist> so the only thing creating them is the DAO
[17:04:20 EDT(-0400)] <athena> sounds great
[17:04:50 EDT(-0400)] <athena> i think we'll just need to inject the channel store into a few places so we can call newChannel and newChannelType?
[17:05:00 EDT(-0400)] <EricDalquist> yeah
[17:05:06 EDT(-0400)] <EricDalquist> that was a question too though
[17:05:20 EDT(-0400)] <EricDalquist> so all of the portlet DAOs you can't create an 'unattached' object
[17:05:45 EDT(-0400)] <EricDalquist> only the DAO can create new JPA backed IPortletDefinition objects and it stores them immediately
[17:06:11 EDT(-0400)] <EricDalquist> the up side to that is it greatly simplifies the DAO since you don't have to worry if the object has been persisted or not
[17:06:15 EDT(-0400)] <athena> yeah
[17:06:25 EDT(-0400)] <EricDalquist> the down side is you need all the arguments to create a valid object up front
[17:06:35 EDT(-0400)] <athena> yeah
[17:06:41 EDT(-0400)] <athena> it seems like that would be awkward with the channels
[17:06:52 EDT(-0400)] <athena> since there's so many properties
[17:07:07 EDT(-0400)] <EricDalquist> yeah
[17:07:20 EDT(-0400)] <athena> also, we'll have some properties that the user specifies, and some that maybe only get created in the service code - like the timestamps
[17:07:27 EDT(-0400)] <EricDalquist> yup
[17:15:15 EDT(-0400)] <EricDalquist> so is it ok if I commit a few of these changes
[17:15:20 EDT(-0400)] <EricDalquist> it does involve a few moved files
[17:16:41 EDT(-0400)] <EricDalquist> hrm
[17:16:47 EDT(-0400)] <EricDalquist> actually my local patch is messed up
[17:16:55 EDT(-0400)] <EricDalquist> well I'll keep playing around with it
[17:17:04 EDT(-0400)] <EricDalquist> and may have a few tweaks to go in this weekend to help out a birt
[17:17:13 EDT(-0400)] <EricDalquist> I have to run, catch you later!
[20:51:57 EDT(-0400)] * lennard1 (n=sparhk@wsip-98-174-242-39.ph.ph.cox.net) has left ##uportal