[09:30:42 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[09:41:09 EST(-0500)] * bszabo (n=bszabo@ip72-208-41-138.ph.ph.cox.net) has joined ##uportal
[10:05:23 EST(-0500)] * lennard1 (n=sparhk@ip68-98-56-21.ph.ph.cox.net) has left ##uportal
[10:21:41 EST(-0500)] * lennard1 (n=sparhk@uni1.unicon.net) has joined ##uportal
[10:30:47 EST(-0500)] * michelled (n=team@142.150.154.197) has joined ##uportal
[10:36:36 EST(-0500)] * lennard1 (n=sparhk@uni1.unicon.net) has left ##uportal
[10:37:33 EST(-0500)] * holdorph (n=holdorph@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[10:39:45 EST(-0500)] * lennard1 (n=sparhk@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[10:45:46 EST(-0500)] * athena7 (n=athena7@12.164.139.7) has joined ##uportal
[10:49:14 EST(-0500)] <dstn> athena7, I'm not seeing any database schema changes between yale's calendar portlet and the one in trunk but wanted to confirm with you?
[11:08:07 EST(-0500)] <lennard1> hot deploying a portlet does not work in uPortal 2.6.1 but does work in uPortal 3.x, is that correct?
[11:10:24 EST(-0500)] <dstn> yes
[11:10:57 EST(-0500)] <dstn> I've noticed you may have to reload the context in tomcat manager to pick up changes to say a log4j.properties file
[11:11:29 EST(-0500)] <EricDalquist> dstn: if you use the Spring log4j loader that fixes the problem
[11:11:32 EST(-0500)] <dstn> also, look at removeExisting property so you don't run into classloading issues
[11:11:40 EST(-0500)] <EricDalquist> yup
[11:14:41 EST(-0500)] <athena7> dstn: yes, that's correct
[11:14:59 EST(-0500)] <dstn> athena7: thank you
[11:15:03 EST(-0500)] <athena7> we'd like to eventually make them keyed by a calendar set id, but before doing that i'd add import/export so that people can transition
[11:15:08 EST(-0500)] <athena7> there are new APIs
[11:15:13 EST(-0500)] <athena7> but no db-level changes
[11:16:01 EST(-0500)] <athena7> so you'll need to update any yale-specific code, plus make some updates to the calendar data itself
[11:16:18 EST(-0500)] <athena7> although you could get around that by aliasing the old adapter ids to the new ones
[11:19:57 EST(-0500)] <dstn> Ya, I'm noticing that subscribeid was used in the past and now it's username
[11:20:28 EST(-0500)] <dstn> I'm assuming that's going to cause some data migration issues based on reading some of your wiki comments
[11:23:28 EST(-0500)] <dstn> Also, I'm looking at https://www.ja-sig.org/svn/portlets/CalendarPortlet/trunk/src/main/java/edu/yale/its/tp/portlets/calendar/url/CasProxyUrlCreatorImpl.java and it doesn't look like it supports URL's with parameters
[11:36:40 EST(-0500)] <athena7> well
[11:36:45 EST(-0500)] <athena7> it was always sort of username
[11:37:00 EST(-0500)] <athena7> but we allowed it to be a subscribe id so that you could have multiple instances per user
[11:37:07 EST(-0500)] <athena7> we'll probably rip that out though
[11:37:29 EST(-0500)] <athena7> that's a good point dstn - can you file a ticket for the cas proxy url?
[11:37:55 EST(-0500)] <dstn> ya
[11:39:20 EST(-0500)] <athena7> tagging it to subscribe id is really incompatible with import/export
[11:39:29 EST(-0500)] <athena7> and probably just generally a bad idea at this point
[11:39:35 EST(-0500)] <athena7> so eventually we'll rename the db field
[11:39:58 EST(-0500)] <athena7> and create a concept of calendar sets
[11:42:23 EST(-0500)] <dstn> What exactly is the SubscribeID?
[11:42:40 EST(-0500)] <dstn> I'm it's tied to the specific instance of the portlet...?
[11:42:52 EST(-0500)] <dstn> here's the issue: http://www.ja-sig.org/issues/browse/CAP-16
[11:44:00 EST(-0500)] <dstn> I'm still unsure how (if) data is going to be migrated if it's keyed by SubscribeID
[11:44:44 EST(-0500)] <dstn> I don't think "Sorry, we lost you're data in the upgrade" is going to be acceptable
[11:48:09 EST(-0500)] <dstn> also, what happened to predefinedEditActions in EditCalendarPreferencesController?
[12:04:26 EST(-0500)] <athena7> a subscribe id is an internal uportal thing - the unique id for that channel instance in the user's layout
[12:04:44 EST(-0500)] <athena7> is yale's keyed by subscribe id or user id?
[12:04:59 EST(-0500)] <EricDalquist> athena7: how are you getting that value in the portlet?
[12:05:19 EST(-0500)] <athena7> we had a custom extension of the portlet adapter thing that put it in the user info
[12:05:20 EST(-0500)] <EricDalquist> I didn't think the portal exposed that to the portlet
[12:05:22 EST(-0500)] <EricDalquist> ah
[12:05:25 EST(-0500)] <athena7> as i mentioned, none of it was a very good idea
[12:05:31 EST(-0500)] <EricDalquist> yeah :/
[12:05:57 EST(-0500)] <athena7> especially now, since the subscribe id changes when you do an export/import
[12:06:13 EST(-0500)] <athena7> dstn: sorry, predefinedEditAction?
[12:08:17 EST(-0500)] <athena7> does it not seem to work anymore?
[12:11:15 EST(-0500)] <athena7> EricDalquist: what day were you planning to cut the milestone?
[12:12:41 EST(-0500)] <EricDalquist> Wednesday{color}
[12:12:51 EST(-0500)] <EricDalquist> plan/hope something like that
[12:14:00 EST(-0500)] <athena7> cool 
[12:16:20 EST(-0500)] <athena7> i'll make sure to get any UI changes checked in by then
[12:16:42 EST(-0500)] <EricDalquist> great
[12:17:10 EST(-0500)] <EricDalquist> how much work would it take to get the framework's use of JS to comply with the "multiple versions of jQuery" talks we've been having?
[12:18:15 EST(-0500)] <athena7> i should check with fluid
[12:18:19 EST(-0500)] <athena7> we're getting really close
[12:18:43 EST(-0500)] <athena7> if nothing else, what i'll do is set it to jQuery.noConflict(false) (which is no conflict mode, but not extreme no conflict)
[12:18:55 EST(-0500)] <athena7> if i can get it working, though, i'll add the extreme mode
[12:19:13 EST(-0500)] <athena7> turns out there were some references in fluid code and dependencies to "jQuery"
[12:19:24 EST(-0500)] <athena7> i think after jlee's help, we're doing ok with the datepicker
[12:20:37 EST(-0500)] <athena7> http://issues.fluidproject.org/browse/FLUID-2165
[12:20:50 EST(-0500)] <EricDalquist> nice
[12:23:00 EST(-0500)] <athena7> so i'll check in and see how much of that's fixed - looks like there's been some work done
[12:25:22 EST(-0500)] <[jlee]> let me know if I can help otherwise. With jQuery.noConflict(false), you will still run into issues if multiple plugins are using the same namespace (ie, different versions of plugins). but as long as you don't use the same plugins more than once on a page, you should be okay
[12:26:28 EST(-0500)] <athena7> hm
[12:26:47 EST(-0500)] <athena7> i think we can almost guarantee we'll be using multiple versions of the same plugins
[12:27:30 EST(-0500)] <athena7> but if we import them with different jQuery imports, will it work?
[12:28:16 EST(-0500)] <[jlee]> actually, let me double check something real quick.. I somewhat recall reading on their changelogs that they may have added some code to fix that issue a little while back
[12:35:12 EST(-0500)] <[jlee]> hmm.. looks like the issue is still there 
[12:35:35 EST(-0500)] <[jlee]> will you ever have multiple instances of the same Fluid code (that has references to the jQuery object)?
[12:36:20 EST(-0500)] <[jlee]> that's the main problem... any code that directly references the jQuery object will most likely run into issues if multiple instances exist on the page
[12:37:56 EST(-0500)] <[jlee]> whether you have extreme mode on or off... the only thing that extreme mode 'on' gives you is that you will see a javascript error (identifying the problem areas in your code), where as extreme mode 'off' will just produce erratic behavior
[13:02:38 EST(-0500)] <athena7> jlee - will we have problems if the mulitple instances are loaded into separate jQuery objects?
[13:02:57 EST(-0500)] <athena7> or does that just not work?
[13:03:24 EST(-0500)] * apetro (n=apetro@12.164.139.7) has joined ##uportal
[13:05:50 EST(-0500)] <[jlee]> I think you will still have problems... whenever you have code referencing the jQuery object directly, it does so in the window namespace... so you will run into situations where instance1 code will be calling methods from instance 2 code
[13:09:31 EST(-0500)] <athena7> argh
[13:09:41 EST(-0500)] <athena7> so this really just won't help us at all - it sounds like we're back to square one
[13:09:45 EST(-0500)] <athena7> bbiab, i have a meeting
[13:10:04 EST(-0500)] <[jlee]> yeah – best bet is to get rid of any global references from your plugin / fluid code
[13:11:32 EST(-0500)] <dstn> athena7: sorry, I was looking for predefinedEditActions in EditCalendarPreferencesController but its in EditCalendarSubscriptionsController now
[13:13:03 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[13:14:58 EST(-0500)] <EricDalquist> [jlee]: I've heard you talking about an 'unobtrusive javascript' book, could you point me in its direction?
[13:21:29 EST(-0500)] <EricDalquist> uhg so I have another JS question ...
[13:21:40 EST(-0500)] <EricDalquist> we have developers using a 3.0 quickstart locally for development
[13:21:53 EST(-0500)] <EricDalquist> but in our deployed env we have none of the portal JS loading
[13:22:22 EST(-0500)] <EricDalquist> and I need to figure out a way for them to hook into the document.load functionality in their portlet
[13:30:01 EST(-0500)] <dstn> face of the planet...lol
[13:32:39 EST(-0500)] <[jlee]> EricDalquist: hmm... not sure about the unobtrusive javascript book reference... there are a lot of good references on the web on unobtrusive javascript best practices, but don't really have a specific book in mind.
[13:32:53 EST(-0500)] <[jlee]> a good jQuery primer: http://simonwillison.net/static/2008/xtech/
[13:33:32 EST(-0500)] <[jlee]> so trying to follow your issue, re: portal JS not loading...
[13:33:56 EST(-0500)] <[jlee]> you have javascript functions defined on the portal level that you want called when a portlet is done loading?
[13:34:59 EST(-0500)] <EricDalquist> well we have javascript we want to run in the portlet when the page finishes loading
[13:35:10 EST(-0500)] <EricDalquist> but the portlet can't contribute to the head
[13:37:43 EST(-0500)] <jayshao> can you use an embedded script to add items to the event handler?
[13:41:00 EST(-0500)] <[jlee]> yes, so if you're using jQuery, you will want to put whatever javascript code you want to execute after pageLoad within the document.ready event handler.
[13:41:03 EST(-0500)] <[jlee]> it looks like this:
[13:41:18 EST(-0500)] <[jlee]> jQuery(document).ready(function() {
[13:41:25 EST(-0500)] <[jlee]> // your methods here
[13:41:30 EST(-0500)] <[jlee]> });
[13:41:40 EST(-0500)] <EricDalquist> ok
[13:42:19 EST(-0500)] <[jlee]> of course, if you're renamed the jQuery object using noConflict, you will have to use that name, instead of "jQuery"
[13:42:35 EST(-0500)] <[jlee]> *you're=you've
[13:42:40 EST(-0500)] <EricDalquist> yeah, I'll need to check on the environments
[13:42:52 EST(-0500)] <EricDalquist> I'm concerned their local env has jquery imported and isn't using noconflict
[13:43:00 EST(-0500)] <EricDalquist> and our actual env doesn't have jquery imported
[13:44:11 EST(-0500)] <[jlee]> so the 3.0 quickstart doesn't use jquery?
[13:44:20 EST(-0500)] <EricDalquist> I can't remember
[13:44:25 EST(-0500)] <EricDalquist>
[13:44:40 EST(-0500)] <EricDalquist> I'll be finding out in a little bit
[13:44:45 EST(-0500)] <EricDalquist> athena7: do you remember?
[13:44:58 EST(-0500)] <[jlee]> if you need to use native javascript, (instead of jQuery) here's how to do it...
[13:45:19 EST(-0500)] <[jlee]> function onLoadHandler() {
[13:45:23 EST(-0500)] <[jlee]> // methods here
[13:45:27 EST(-0500)] <[jlee]> }
[13:45:31 EST(-0500)] <athena7> the quickstart uses jquery, yes
[13:45:32 EST(-0500)] <[jlee]> window.onload = onLoadHandler
[13:45:38 EST(-0500)] <athena7> so jlee i think i might have misread you before
[13:45:39 EST(-0500)] <[jlee]> ;
[13:45:55 EST(-0500)] <athena7> if we don't have things that actually say "jQuery" we should be able to use multiple versions?
[13:45:57 EST(-0500)] <EricDalquist> great, thanks [jlee]. will that break other onload handlers?
[13:46:00 EST(-0500)] <athena7> fluid's already agreed to fix up their code
[13:46:07 EST(-0500)] <[jlee]> athena7: yes, that's correct
[13:46:20 EST(-0500)] <athena7> oh! we're all set then
[13:46:21 EST(-0500)] <athena7> thanks
[13:46:32 EST(-0500)] <[jlee]> EricDalquist: yeah.. it will... so if you don't want to overwrite other onload handlers, you need to call the old one like this...
[13:46:58 EST(-0500)] <[jlee]> var oldOnload = window.onload;
[13:47:20 EST(-0500)] <[jlee]> function onLoadHandler() {
[13:48:28 EST(-0500)] <[jlee]> oldOnload.apply(this, arguments);
[13:48:32 EST(-0500)] <[jlee]> // methods here
[13:48:36 EST(-0500)] <[jlee]> }
[13:48:42 EST(-0500)] <[jlee]> window.onload = oldOnload;
[13:50:10 EST(-0500)] <[jlee]> athena7: sorry bout the confusion!
[13:50:32 EST(-0500)] <EricDalquist> wonderful
[14:09:40 EST(-0500)] <[jlee]> EricDalquist: if jQuery is imported, I would go ahead and use theirs (document.ready), as they do some extra cross-browser work to prevent a nasty IE memory leak
[14:10:13 EST(-0500)] <EricDalquist> [jlee]: the problem is a local dev env versus our actual env
[14:10:21 EST(-0500)] <EricDalquist> the local dev version has jQuery
[14:10:28 EST(-0500)] <EricDalquist> the actual env does not
[14:10:29 EST(-0500)] <[jlee]> also, window.onload waits until the page is FULLY loaded (including all images)... whereas jQuery's document ready fires when the DOM is fully loaded
[14:50:21 EST(-0500)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
Page Comparison
General
Content
Integrations