[05:59:26 EDT(-0400)] * higmad (n=chatzill@pcit-8752.HIG.SE) has joined ##uportal
[08:33:37 EDT(-0400)] * EricDalquist (n=EricDalq@adsl-76-208-69-153.dsl.mdsnwi.sbcglobal.net) has joined ##uportal
[08:42:24 EDT(-0400)] * colinclark (n=colin@bas2-toronto09-1176131209.dsl.bell.ca) has joined ##uportal
[08:42:33 EDT(-0400)] * anastasiac (n=stasia@142.150.154.189) has joined ##uportal
[08:56:50 EDT(-0400)] * EricDalquist (n=EricDalq@adsl-76-208-69-153.dsl.mdsnwi.sbcglobal.net) has joined ##uportal
[09:15:28 EDT(-0400)] * athena (n=athena@dhcp128036158215.central.yale.edu) has joined ##uportal
[09:16:48 EDT(-0400)] <dstn> So I have a subscribe_id n958 in this external table but in up_layout_struct I see no struct_id of 958. Does this mean the channel was deleted? Do values get deleted out of up_layout_struct when you delete a channel?
[09:17:18 EDT(-0400)] <EricDalquist> the user probably removed the channel from their layout
[09:18:08 EDT(-0400)] <EricDalquist> and no, when you delete a channel nothing gets deleted from the layouts
[09:18:17 EDT(-0400)] <EricDalquist> actually nothing gets delete from up_channel
[09:18:31 EDT(-0400)] <EricDalquist> the channel is really just marked inactive
[09:20:08 EDT(-0400)] * athena (n=athena@dhcp128036158215.central.yale.edu) has joined ##uportal
[09:38:01 EDT(-0400)] * fj4000 (n=Jacob@142.150.154.106) has joined ##uportal
[09:41:51 EDT(-0400)] <EricDalquist> hrm ... just found an annoying channel/portlet missmatch
[09:42:12 EDT(-0400)] <EricDalquist> the error channel is essentially a portlet entity level thing
[09:42:42 EDT(-0400)] <EricDalquist> so as support for transient portlet windows (exclusive/detached) appears the error handling gets confusing
[09:42:50 EDT(-0400)] <athena> ah
[09:42:51 EDT(-0400)] <athena> hm
[09:43:00 EDT(-0400)] <EricDalquist> I'm not sure how much longer we can keep up the portal>channel>portlet abstraction
[09:43:26 EDT(-0400)] <athena> is it a useful abstraction to maintain going forward?
[09:43:29 EDT(-0400)] <EricDalquist> I'm thinking the rendering code is going to need to be refactored fairly soon to make portlets top-level items
[09:43:32 EDT(-0400)] <EricDalquist> not really
[09:43:34 EDT(-0400)] <athena> gotcha
[09:43:39 EDT(-0400)] <EricDalquist> it was left because it was easier
[09:43:42 EDT(-0400)] * athena advocates death to channels
[09:43:57 EDT(-0400)] <EricDalquist> I'm guessing that when we try to integrate portlet 2.0 it will have to go away
[09:44:10 EDT(-0400)] <EricDalquist> I think having a channel adaptor portlet would be doable though
[09:44:45 EDT(-0400)] <EricDalquist> I did get detached working for portlets though 
[09:45:24 EDT(-0400)] * colinclark (n=colin@bas2-toronto09-1176131209.dsl.bell.ca) has joined ##uportal
[09:46:26 EDT(-0400)] <athena> awesome
[09:46:35 EDT(-0400)] <EricDalquist> yeah
[09:46:39 EDT(-0400)] <athena> and i like the idea of having a channel adaptor portlet, for backwards compatibility
[09:46:46 EDT(-0400)] <EricDalquist> should work well if a portlet needs to do a pop-up
[09:46:52 EDT(-0400)] <athena> awesome
[09:49:49 EDT(-0400)] <EricDalquist> I wish there was a css "reset" style
[09:50:06 EDT(-0400)] <EricDalquist> so I could stick it around the inner most portal rendered div that wraps each portlet
[10:10:55 EDT(-0400)] * jessm (n=Jess@c-71-232-3-4.hsd1.ma.comcast.net) has joined ##uportal
[10:22:52 EDT(-0400)] * lennard1 (n=sparhk@ip68-98-56-21.ph.ph.cox.net) has left ##uportal
[10:41:33 EDT(-0400)] * lennard1 (n=sparhk@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[10:49:37 EDT(-0400)] * michelled (n=team@142.150.154.193) has joined ##uportal
[11:06:37 EDT(-0400)] * apetro (n=apetro@ip68-3-207-51.ph.ph.cox.net) has joined ##uportal
[11:07:41 EDT(-0400)] * colinclark (n=colin@bas2-toronto09-1176131209.dsl.bell.ca) has joined ##uportal
General
Content
Integrations