[00:17:01 EDT(-0400)] * Tuomaz_ (n=fredrik@ip223.taftea.se) has joined ##uportal
[00:17:40 EDT(-0400)] * ChanServ (ChanServ@services.) has joined ##uportal
[00:55:20 EDT(-0400)] * Sememmon (n=Sememmon@ip70-190-32-223.ph.ph.cox.net) has joined ##uportal
[01:08:07 EDT(-0400)] * Sememmon (n=Sememmon@ip70-190-32-223.ph.ph.cox.net) has joined ##uportal
[01:15:19 EDT(-0400)] * Sememmon (n=Sememmon@ip70-190-32-223.ph.ph.cox.net) has joined ##uportal
[03:36:51 EDT(-0400)] * higmad (n=chatzill@pcit-8752.HIG.SE) has joined ##uportal
[09:04:00 EDT(-0400)] * athena (n=athena@99.129.100.66) has joined ##uportal
[09:05:56 EDT(-0400)] <Tuomaz> athena: good morning
[09:06:11 EDT(-0400)] <athena> morning (yes, EDT here)
[09:07:11 EDT(-0400)] <Tuomaz> The clock is 15.07 here (Sweden)
[09:07:28 EDT(-0400)] <athena> ah
[09:07:30 EDT(-0400)] <Tuomaz> I'm trying out jasig-widget-portlets
[09:07:37 EDT(-0400)] <athena> oh, cool
[09:07:42 EDT(-0400)] <athena> you may be the first to do so
[09:07:46 EDT(-0400)] <Tuomaz>
[09:08:06 EDT(-0400)] <Tuomaz> they are very nice
[09:08:11 EDT(-0400)] <athena> great! i'm glad
[09:08:19 EDT(-0400)] <athena> they could still use some polishing, especially the edit UIs
[09:08:33 EDT(-0400)] <athena> my hope is to keep them small and focused, with only a few config options
[09:08:51 EDT(-0400)] <Tuomaz> yes, that is a nice approach
[09:08:53 EDT(-0400)] <athena> for some of the portlets, if someone wants more powerful config options we already have other portlets that overlap
[09:09:04 EDT(-0400)] <athena> i'd love to just have some easily install-able default content
[09:09:22 EDT(-0400)] <athena> if you have ideas for improvements or notice bugs, definitely let me or the list know
[09:09:23 EDT(-0400)] <Tuomaz> My portal administrator want to have the Google RSS portlet in our production portal
[09:09:35 EDT(-0400)] <athena> oh cool
[09:09:36 EDT(-0400)] <Tuomaz> yes
[09:09:43 EDT(-0400)] <Tuomaz> I have som questions
[09:09:45 EDT(-0400)] <athena> i sort of like the fact that you can search for new feeds
[09:09:46 EDT(-0400)] <athena> sure
[09:10:32 EDT(-0400)] <Tuomaz> When I add the Google RSS portlet to a portal tab, some of the javascript functionality on that tab seems to break (for us at least)
[09:10:49 EDT(-0400)] <Tuomaz> I can't edit the tab layout
[09:10:59 EDT(-0400)] <athena> which version of uportal are you using?
[09:11:04 EDT(-0400)] <Tuomaz> 3.0
[09:11:18 EDT(-0400)] <Tuomaz> Have you noticed this? Or could this have something to with our custom theme+skin
[09:11:37 EDT(-0400)] <athena> no that's not surprising
[09:11:54 EDT(-0400)] <Tuomaz> Ok, uPortal 3.1 is needed?
[09:11:58 EDT(-0400)] <athena> well, not really
[09:12:31 EDT(-0400)] <athena> basically we need to make the portlets configurable so that you can choose whether jQuery is imported by the portlets, and choose whether to use jQuery's noConflict mode
[09:12:42 EDT(-0400)] <athena> for uportal 3.1 we adopted a new strategy for handling javascript
[09:13:28 EDT(-0400)] <athena> which basically involves using noConflict aggressively in the portal itself, and asking each portlet to import jQuery itself, and clear the $ and jQuery variables so that the next portlet will have a clean slate
[09:13:50 EDT(-0400)] <athena> but uportal 3.0 assumes the portlets will use its version of jQuery
[09:15:59 EDT(-0400)] <Tuomaz> ok, so I need to modify the Google RSS portlet so that it doesn't include jQuery, instead it should use the one provided by uPortal?
[09:16:22 EDT(-0400)] <athena> yeah that would work
[09:16:42 EDT(-0400)] <athena> you probably need to modify it to not include jquery and jquery ui
[09:16:54 EDT(-0400)] <athena> and then not have it call jQuery.noConflict
[09:17:44 EDT(-0400)] <Tuomaz> ok
[09:17:46 EDT(-0400)] <Tuomaz> thanx
[09:18:02 EDT(-0400)] <athena> sure
[09:18:06 EDT(-0400)] <athena> let me know if you have problems with it
[09:18:21 EDT(-0400)] <athena> i can't think of anything specific that portlet is using that will require a more recent version of jquery
[09:21:08 EDT(-0400)] <Tuomaz> ok, I will try to make it work in our portal
[09:22:15 EDT(-0400)] <Tuomaz> athena: it is really a very good initiative, to create the jasig-widget-portlets suit
[09:28:58 EDT(-0400)] <athena> i'm really glad you like it
[09:29:06 EDT(-0400)] <athena> i'd love to get them cleaned up enough to ship with uportal someday
[09:38:40 EDT(-0400)] * jessm (n=Jess@c-71-232-1-65.hsd1.ma.comcast.net) has joined ##uportal
[09:53:53 EDT(-0400)] * colinclark (n=colin@bas2-toronto09-1176131435.dsl.bell.ca) has joined ##uportal
[10:09:51 EDT(-0400)] <Tuomaz> for the logs: I have a patch to make the Google RSS portlet work with uPortal 3.0
[10:11:55 EDT(-0400)] <athena> and for public completeness, we need to add some sort of config option so that adopters won't need to patch
[10:12:08 EDT(-0400)] <athena> really i'd like to find a way that we can handle it similarly in other jasig portlets as well
[10:21:48 EDT(-0400)] <Tuomaz> athena: what is these images linked under the famfamfam path? They are not in svn.
[10:21:56 EDT(-0400)] <athena> ah, ok
[10:22:00 EDT(-0400)] <athena> they need to get added
[10:22:08 EDT(-0400)] <athena> thanks for pointing that out
[10:22:31 EDT(-0400)] <athena> the other half of the work we did for 3.1 was to add all javascript and image standard library stuff to a new webapp
[10:22:46 EDT(-0400)] <athena> it's job is just to serve up properly-gzipped, cached static content
[10:23:03 EDT(-0400)] <athena> but for people who aren't running uportal 3.1 we've been adding things to the portlet itself
[10:23:24 EDT(-0400)] <athena> so we can do that for the widgets portlets
[10:23:49 EDT(-0400)] <Tuomaz> ah, ok
[10:25:35 EDT(-0400)] <Tuomaz> there is some logic in the rs tag for that I guess?
[10:26:32 EDT(-0400)] <athena> yeah, basically
[10:26:40 EDT(-0400)] <athena> it checks for the /ResourceServingWebapp context
[10:26:49 EDT(-0400)] <athena> and if it's not found, serves the resource from the local webapp
[10:26:56 EDT(-0400)] <Tuomaz> ok
[10:27:29 EDT(-0400)] <athena> so if we put those images in the magic place in the /rs directory, they'll show up even if you don't have the ResourceServingWebapp installed
[10:27:39 EDT(-0400)] <Tuomaz> yes
[10:28:08 EDT(-0400)] <Tuomaz> Can you put the images in jasig-widget-portlets svn repo?
[10:28:17 EDT(-0400)] <athena> yes
[10:28:44 EDT(-0400)] <Tuomaz> fine!
[10:28:51 EDT(-0400)] <Tuomaz> Time to go home.
[10:55:27 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[11:00:58 EDT(-0400)] <athena> morning EricDalquist
[11:01:05 EDT(-0400)] <EricDalquist> hello
[11:01:25 EDT(-0400)] <athena> you have time to talk about some of the ChannelRegistryManager stuff today?
[11:01:38 EDT(-0400)] <EricDalquist> a bit
[11:01:46 EDT(-0400)] <athena> ok
[11:02:00 EDT(-0400)] <athena> i think we're trying to figure out how much we can do given the time we have
[11:02:10 EDT(-0400)] <athena> i wanted to talk about a couple specifics when you've got a few minutes
[11:03:29 EDT(-0400)] <EricDalquist> ok
[11:04:07 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[11:04:19 EDT(-0400)] <EricDalquist> we can chat now
[11:04:23 EDT(-0400)] <athena> oh ok
[11:04:31 EDT(-0400)] <athena> so basically i'm trying to figure out what we really need
[11:04:36 EDT(-0400)] <athena> and how much new data we need to represent
[11:05:02 EDT(-0400)] <athena> so far, the only really concrete requirement i've got is this: org.jasig.portal.channels.portlet.CSpringPortletAdaptor
[11:05:13 EDT(-0400)] <EricDalquist> so we are talking about the old ChannelRegistryManager?
[11:05:22 EDT(-0400)] <EricDalquist> that tracks stuff in XML?
[11:05:24 EDT(-0400)] <athena> yes
[11:05:39 EDT(-0400)] <athena> and to some extent, the ChannelDefinition data model
[11:05:43 EDT(-0400)] <EricDalquist> ok
[11:05:51 EDT(-0400)] <athena> i think we could actually reuse the existing approvalId and publishId to represent the "reviewed" and "published" state
[11:05:59 EDT(-0400)] * michelled (n=team@142.150.154.193) has joined ##uportal
[11:06:12 EDT(-0400)] <athena> really, it seems like the only thing we really need is a new parallel pair of fields to mark a channel as expired
[11:06:12 EDT(-0400)] <EricDalquist> ok
[11:06:26 EDT(-0400)] * fj4000 (n=Jacob@142.150.154.106) has joined ##uportal
[11:07:10 EDT(-0400)] <athena> that, combined with some new permissions governing which users may perform which lifecycle steps would probably be enough to represent that new lifecycle in the database
[11:07:14 EDT(-0400)] <athena> does that sound right?
[11:07:17 EDT(-0400)] <EricDalquist> sounds right
[11:07:20 EDT(-0400)] <athena> ok
[11:07:38 EDT(-0400)] <EricDalquist> looking at the ChannelDefinition object it looks like there is some cleanup that could be done too
[11:07:49 EDT(-0400)] <athena> what kind of stuff do you have in mind?
[11:08:25 EDT(-0400)] <EricDalquist> like I'd vote to deprecate:
[11:08:25 EDT(-0400)] <EricDalquist> public Element getDocument(Document doc, String idTag, String statusMsg, int errorId) {
[11:08:25 EDT(-0400)] <EricDalquist> public Element getDocument(Document doc, String idTag) {
[11:08:32 EDT(-0400)] <EricDalquist> and move those into some functional class
[11:08:35 EDT(-0400)] <EricDalquist> that actually needs that
[11:08:49 EDT(-0400)] <EricDalquist> its rather random that a data object has XML manipulation methods in it
[11:08:58 EDT(-0400)] <athena> oh jeez
[11:08:59 EDT(-0400)] <EricDalquist> that hard-code error handling parameters no less
[11:09:02 EDT(-0400)] <athena> i didn't even really that was on there
[11:10:02 EDT(-0400)] <EricDalquist> the other thing I'd really like to see is when this work is done a real reference between ChannelDefinition and IPortletDefinition
[11:10:16 EDT(-0400)] <athena> gotcha
[11:10:34 EDT(-0400)] <EricDalquist> so that an IPortletDefinition can only exist iff the corresponding ChannelDefinition also exists
[11:10:49 EDT(-0400)] <athena> we've talked some about whether we can really justify re-writing the channel persistence code with JPA as part of this project, if we only need a couple of new database fields
[11:10:52 EDT(-0400)] <EricDalquist> that should be able to be modeled after the portlet object hierarchy
[11:10:57 EDT(-0400)] <athena> but i'm kind of hoping it wouldn't actually be that time-consuming
[11:11:13 EDT(-0400)] <EricDalquist> I doubt it would be that much more work than editing and testing the existing code
[11:11:21 EDT(-0400)] <athena> yeah that was kind of my guess
[11:11:48 EDT(-0400)] <athena> i think my current proposal is to at least re-implement the RDBM code as JPA, though we may not really have time for sweeping API reforms
[11:12:07 EDT(-0400)] <EricDalquist> what I would really love to see, but I won't hold my breath, is a IChannelDefinition interface and a protected implementation similarly to how the portlet OM works
[11:12:14 EDT(-0400)] <EricDalquist> but that may be too big of a step for this work
[11:12:22 EDT(-0400)] <athena> and to re-create the ChannelRegistryManager as a separate service interface/implementation that calls the DAO
[11:12:26 EDT(-0400)] <athena> yeah i'd really like to see that too
[11:12:42 EDT(-0400)] <EricDalquist> plus the more I've been sketching out how JSR-286 works the more I'm wondering if we're going to have to switch portlets to be our first class objects
[11:12:47 EDT(-0400)] <EricDalquist> and make a channel adaptor
[11:12:54 EDT(-0400)] <athena> gotcha
[11:13:01 EDT(-0400)] <EricDalquist> yeah, that ChannelRegistryManager change would be great
[11:13:10 EDT(-0400)] <EricDalquist> and not have that thing be stateful like it is now
[11:13:15 EDT(-0400)] <athena> yeah
[11:13:16 EDT(-0400)] <EricDalquist> just have it be a OM->XML pass through
[11:13:20 EDT(-0400)] <EricDalquist> stick a cache on it for speed
[11:13:23 EDT(-0400)] <athena> we really don't even need XML
[11:13:30 EDT(-0400)] <EricDalquist> and that would be even better
[11:13:44 EDT(-0400)] <athena> if we remove the CChannelManager class, i think the only thing that will still be using it is DLMUserPreferences
[11:14:08 EDT(-0400)] <athena> so maybe we just leave the old ChannelRegistryManager there, but update everything else to use the new service?
[11:14:21 EDT(-0400)] <athena> and the service could just return List<ChannelDefinition> or something sane
[11:14:31 EDT(-0400)] <EricDalquist> that seems reasonably
[11:14:35 EDT(-0400)] <EricDalquist> reasonable
[11:14:47 EDT(-0400)] <athena> and have some built in spring caching so that we don't keep re-executing the permissions logic
[11:15:06 EDT(-0400)] <EricDalquist> yeah
[11:15:36 EDT(-0400)] <athena> so i guess my current thought is to do kind of the bare minimum needed to create the new service, and also hopefully JPA-ify the channel persistence code
[11:16:24 EDT(-0400)] <EricDalquist> that sounds reasonable
[11:16:32 EDT(-0400)] <athena> but not massively refactor the data model or IChannelRegistryStore API
[11:16:35 EDT(-0400)] <athena> that sound ok?
[11:16:49 EDT(-0400)] <EricDalquist> especially since I think we may end up rolling ChannelDefinition into IPortletDefinition within in the next year to get full 286 support
Page Comparison
General
Content
Integrations