[04:27:14 EST(-0500)] * higmad (n=chatzill@pcit-8752.HIG.SE) has joined ##uportal
[06:54:47 EST(-0500)] * lennard1 (n=sparhk@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[08:16:06 EST(-0500)] * bszabo (n=bszabo@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[09:00:11 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[09:02:52 EST(-0500)] * athena7 (n=athena7@adsl-99-136-251-32.dsl.wlfrct.sbcglobal.net) has joined ##uportal
[09:07:02 EST(-0500)] <athena7> hey EricDalquist - i had a question about your response on the postgres import/export thing
[09:07:10 EST(-0500)] <EricDalquist> ok
[09:07:27 EST(-0500)] <athena7> do we know for sure that there's always transactions available now?
[09:07:48 EST(-0500)] <EricDalquist> we should assume so
[09:07:48 EST(-0500)] <athena7> i was hesitant to do anything transaction-specific in that code since i saw there was a supportsTransactions test
[09:07:59 EST(-0500)] <EricDalquist> I don't think the portal will work right on a db without Tx support
[09:08:10 EST(-0500)] <athena7> ok, thanks
[09:08:17 EST(-0500)] <athena7> i figured that might be the case but i wanted to make sure
[09:08:29 EST(-0500)] <athena7> wonder if we want to keep that test there
[09:10:11 EST(-0500)] <EricDalquist> yeah ... we can probably just hardcode it to true and move the test to the portal startup checks
[09:10:19 EST(-0500)] <EricDalquist> if it fails then fail starting the portal?
[09:10:40 EST(-0500)] <athena7> yeah, probably a good idea if we're counting on it
[09:11:53 EST(-0500)] <athena7> so will the transaction manager allow us to cleanly start a new transaction if there's already one running?
[09:17:43 EST(-0500)] <EricDalquist> yes
[09:18:35 EST(-0500)] <EricDalquist> let me find an example ....
[09:19:30 EST(-0500)] <EricDalquist> so in the code that does the join tests ....
[09:19:34 EST(-0500)] <EricDalquist> you'd inject a PlatformTransactionManager
[09:20:00 EST(-0500)] <EricDalquist> then in the afterPropertiesSet you would setup a local TransactionTemplate like:
[09:20:02 EST(-0500)] <EricDalquist> this.transactionTemplate = new TransactionTemplate(this.transactionManager);
[09:20:02 EST(-0500)] <EricDalquist> this.transactionTemplate.setPropagationBehavior(TransactionTemplate.PROPAGATION_REQUIRES_NEW);
[09:20:02 EST(-0500)] <EricDalquist> this.transactionTemplate.afterPropertiesSet();
[09:20:42 EST(-0500)] <EricDalquist> that propagation behavior setting there ensures that when you do: this.transactionTemplate.execute(TransactionCallback) it will happen in a new transaction
[09:20:58 EST(-0500)] <EricDalquist> handling creating a new connection and everything
[09:21:29 EST(-0500)] <athena7> ok, that makes sense
[09:24:41 EST(-0500)] * apetro (n=apetro@12.164.139.7) has joined ##uportal
[09:24:43 EST(-0500)] <athena7> by the way, did you have any thoughts on the multi-profile stuff?
[09:24:59 EST(-0500)] <EricDalquist> I haven't had a chance to read it yet
[09:25:04 EST(-0500)] <EricDalquist> last week was a bit crazy
[09:25:14 EST(-0500)] <EricDalquist> I had LASIK on Wednesday so I wasn't working much
[09:26:02 EST(-0500)] <athena7> oh! how'd it go?
[09:26:04 EST(-0500)] <athena7> that's cool 
[09:26:10 EST(-0500)] <EricDalquist> good
[09:26:14 EST(-0500)] <EricDalquist> I can still see 
[09:26:17 EST(-0500)] <athena7> i don't think i can even imagine not having contacts
[09:26:18 EST(-0500)] <EricDalquist> actually I can see very well
[09:26:21 EST(-0500)] <athena7> well that's a plus
[09:26:30 EST(-0500)] <EricDalquist> my eyes have been feeling better every day
[09:26:34 EST(-0500)] <athena7> that's awesome
[09:26:35 EST(-0500)] <athena7> congrats!
[09:26:46 EST(-0500)] <EricDalquist> the worst of the discomfort is no worse than having old contacts in
[09:27:12 EST(-0500)] <athena7> very cool
[09:40:00 EST(-0500)] <dstn> in uPortal 3.0.2 when I drag a portlet sometimes the page just entirely reloads and hangs mid-drag. Anyone experienced that before?
[09:40:16 EST(-0500)] <dstn> doesn't seem to be one specific portlet either
[09:48:12 EST(-0500)] <athena7> actually that is odd
[09:48:24 EST(-0500)] <athena7> that's a known problem for portlets that contain document.write statements
[09:48:32 EST(-0500)] <athena7> particularly anything using a google API
[09:48:50 EST(-0500)] <athena7> but i haven't seen it happen with portlets that don't have that kind of javascript
[09:49:35 EST(-0500)] <athena7> EricDalquist: would it be unreasonable to just pull out the code for the individual query test into a new method and mark it @Transactional(propagation=Propagation.REQUIRES_NEW)?
[09:50:07 EST(-0500)] <EricDalquist> well remember aspects usually only get applied for external calls into a class
[09:50:25 EST(-0500)] <EricDalquist> methodA calling methodB won't trigger aspects unless you're using CGLIB to rewrite the actual class
[09:50:28 EST(-0500)] <athena7> oh.
[09:50:35 EST(-0500)] <athena7> crap, yeah, i always do forget about that
[09:50:35 EST(-0500)] <EricDalquist> so you could refactor them out into a separate class
[09:50:41 EST(-0500)] <athena7> repeatedly
[10:14:56 EST(-0500)] <athena7> i don't know why i always forget that about transactions
[10:15:03 EST(-0500)] <athena7> anyway, this all seems to work as expected
[10:15:07 EST(-0500)] <athena7> er, about annotations
[10:16:59 EST(-0500)] <EricDalquist> the fix is workin?
[10:19:02 EST(-0500)] <athena7> yep
[10:19:09 EST(-0500)] <athena7> everything seems fine
[10:19:13 EST(-0500)] <EricDalquist> awesome!
[10:19:19 EST(-0500)] <athena7> cleaning it up now and stripping out the transaction stuff
[10:19:35 EST(-0500)] <athena7> it'll be so nice to actually be able to use all the import/export features!
[10:22:25 EST(-0500)] <EricDalquist> can you apply the patch to trunk and the patches branch?
[10:23:14 EST(-0500)] <athena7> yes
[10:23:42 EST(-0500)] <athena7> are we still copying stuff over with the svn tool or are we just applying fixes separately now?
[10:28:10 EST(-0500)] <EricDalquist> either
[10:28:14 EST(-0500)] <EricDalquist> I use svnmerge
[10:28:20 EST(-0500)] <EricDalquist> but I'm not going to force anyone else to
[10:28:36 EST(-0500)] <athena7> i'm fine with that
[10:29:00 EST(-0500)] <athena7> figure if we're still using svnmerge for that branch it'd make more sense to do it that way, since then it'll show up as merged for you later
[10:29:08 EST(-0500)] <EricDalquist> yup
[10:29:16 EST(-0500)] <athena7> the UI stuff is all beyond mergeability at this point, sadly
[10:29:23 EST(-0500)] <EricDalquist> yeah
[10:29:26 EST(-0500)] <athena7> i do need to go back in and fix some stuff in the patches branch though
[10:29:33 EST(-0500)] <EricDalquist> I recently went through and marked a bunch of that as blocked
[10:29:34 EST(-0500)] <athena7> i think there's the IE bug and something else
[10:29:37 EST(-0500)] <athena7> thanks
[10:29:42 EST(-0500)] <EricDalquist> there are a lot of things that have diverged
[10:29:46 EST(-0500)] <EricDalquist> but that's too be expected
[10:29:56 EST(-0500)] <athena7> yeah
[10:29:57 EST(-0500)] <athena7> definitely
[10:30:07 EST(-0500)] <athena7> by the way - speaking of javascript
[10:30:26 EST(-0500)] <athena7> when we talked about the javascript service last week, did you really mean a jar, or a war?
[10:30:48 EST(-0500)] <EricDalquist> well a jar, then people can easily include it in their existing portlet WARs
[10:31:05 EST(-0500)] <EricDalquist> and we'd just have to document the web.xml snippet to add in
[10:31:45 EST(-0500)] <athena7> i guess the impression i got from our original conversations was that we'd have a separate war, and that the portlets could then just reference that url
[10:32:05 EST(-0500)] <EricDalquist> ah, well I guess we had two things we talked about
[10:32:16 EST(-0500)] <athena7> otherwise i think we actually would be downloading the same file several times in the same page, since they'd have different urls
[10:32:20 EST(-0500)] <EricDalquist> the simpler being a little servlet fitler in a jar that sets the cache headers and such
[10:32:32 EST(-0500)] <EricDalquist> the more complex would be a separate war
[10:32:43 EST(-0500)] <EricDalquist> the problem with the separate war approach is it ties the portlet to this other WAR
[10:32:59 EST(-0500)] <dstn> Anyone know what "3rd-level guest caching" is? Announcement portlet says it has it...
[10:33:14 EST(-0500)] <EricDalquist> and if the cache headers are set right the initial cost of downloading those different JS files only happens once
[10:33:35 EST(-0500)] <EricDalquist> I think we get a long way and a good ammount of flexibility with just the servlet filter
[10:33:40 EST(-0500)] <athena7> even with caching, i think that still might be far too much javascript for a lot of people's comfort
[10:33:42 EST(-0500)] <EricDalquist> and good js naming practices
[10:34:12 EST(-0500)] <athena7> we could easily wind up with 10 times the amount of imported code we'd need if it were shared
[10:34:15 EST(-0500)] <EricDalquist> yeah ... I guess I'm just worried about the logistics of maintaining this external war
[10:34:31 EST(-0500)] <athena7> dstn: i'm not sure, maybe ask erik?
[10:35:00 EST(-0500)] <dstn> ok, just thought I'd through it out there
[10:35:10 EST(-0500)] <EricDalquist> I think if people are that worried they look at a service like Google AJAX hosting
[10:35:13 EST(-0500)] <athena7> in some ways i think it would be easier than having to upgrade all the portlets and uportal when changes were made to the servlet filter tool
[10:35:29 EST(-0500)] <athena7> right, but that does what the war would do, not the jar
[10:35:32 EST(-0500)] <EricDalquist> well I guess they are just two diferent uses
[10:35:36 EST(-0500)] <athena7> yeah
[10:35:39 EST(-0500)] <EricDalquist> the filter shouldn't even need an upgrade
[10:35:46 EST(-0500)] <EricDalquist> it just forces GZIP
[10:35:52 EST(-0500)] <EricDalquist> and sets 3 headers or so
[10:36:02 EST(-0500)] <athena7> by the way, have you tried using tomcat's built-in gzip compression?
[10:36:12 EST(-0500)] <EricDalquist> no
[10:36:31 EST(-0500)] <athena7> i don't know if it has any issues with higher load, or anything like that
[10:36:45 EST(-0500)] <athena7> but actually it seemed to work pretty well on our demo servers
[10:37:05 EST(-0500)] <EricDalquist> well I'm assuming it would increase CPU usage
[10:37:15 EST(-0500)] <athena7> yeah i'd assume so
[10:37:16 EST(-0500)] <EricDalquist> but I can't imagine it would be an issue in uPortal
[10:37:20 EST(-0500)] <EricDalquist> which is rarely CPU limited
[10:37:33 EST(-0500)] <athena7> i figured i'd turn that on for the time being since we hadn't hashed all this out yet
[10:37:48 EST(-0500)] <athena7> it's kind of nice, since it automatically gzips scripts, css, html, whatever
[10:38:29 EST(-0500)] <EricDalquist> so I think we have two goals for JS in portlets
[10:38:55 EST(-0500)] <EricDalquist> 1. developers use well named files (version numbers included) and use a servlet fitler to set aggressive caching headers
[10:39:01 EST(-0500)] <EricDalquist> 2. shared JS hosting
[10:39:13 EST(-0500)] <EricDalquist> 2 would be a local form of the Google AJAX Hosting service
[10:39:25 EST(-0500)] <EricDalquist> where the WAR includes a whole bunch of different JS frameworks
[10:39:36 EST(-0500)] <EricDalquist> provides standard and minified versions
[10:39:50 EST(-0500)] <EricDalquist> and uses the same filter to gzip and set caching headers
[10:40:05 EST(-0500)] <athena7> sounds good
[10:40:14 EST(-0500)] <EricDalquist> heck if you really want to save CPU you the filter could use java.io.tmpdir to cache gziped versions of the files
[10:40:27 EST(-0500)] <EricDalquist> or even cache them in memory as a byte[]
[10:40:33 EST(-0500)] <athena7> yeah i wondered if we were worried about needing to cache
[10:40:36 EST(-0500)] <EricDalquist> you could use the same source data for all requests then
[10:40:53 EST(-0500)] <EricDalquist> so I think 1 could be a stand-alone JAR
[10:40:59 EST(-0500)] <EricDalquist> allowing portlet devs to use the servlet as is
[10:41:15 EST(-0500)] <EricDalquist> and 2 could use 1 and then allow portal integrators to centralize their JS hosting
[10:41:46 EST(-0500)] <athena7> sounds good
[10:42:02 EST(-0500)] <athena7> i still need to get back in touch with jlee about the multiple versions stuff
[10:42:07 EST(-0500)] <athena7> i've yet to get any of that to actually work
[10:42:27 EST(-0500)] <EricDalquist> with the jQuery loading example in the wiki?
[10:42:49 EST(-0500)] <athena7> yeah, although our stuff is more complex than that
[10:43:04 EST(-0500)] <athena7> i'll have to see if i can find some time for that today
[10:43:24 EST(-0500)] * holdorph (n=holdorph@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[10:43:45 EST(-0500)] <EricDalquist> looking at that example I'm guessing you need to modify any reference to $ in your script to be $ns
[10:43:56 EST(-0500)] <EricDalquist> or use the portlet specific namespace like the example shows
[10:44:10 EST(-0500)] <EricDalquist> where it aliases $ back to jQuery inside the portlet namespace object
[10:45:13 EST(-0500)] <athena7> yeah, most of our code actually uses the (function($){ })(jQuery); style
[10:45:47 EST(-0500)] <athena7> so that part should be all safe
[10:46:07 EST(-0500)] <EricDalquist> I don't understand enough about JS or jQuery to understand that
[10:46:11 EST(-0500)] <athena7>
[10:46:18 EST(-0500)] <athena7> i'm thinking that once we get everything cleaned up it might make sense to go back and fix the patches branch
[10:46:28 EST(-0500)] <athena7> so that people can run newer portlets with 3.0.x if they need to
[11:20:07 EST(-0500)] * jlee|afk (n=jlee_lap@adsl-074-184-125-241.sip.asm.bellsouth.net) has joined ##uportal
[11:28:45 EST(-0500)] <athena7> is issue UP-2220 (Importing v2.6 layout documents into v3.1 uPortal not working) still open?
[11:28:49 EST(-0500)] <athena7> hey jlee
[11:29:06 EST(-0500)] <jlee> hey
[11:29:26 EST(-0500)] <athena7> in the instructions you gave us last week, do you know if running w/ extreme noconflict is required?
[11:29:44 EST(-0500)] <EricDalquist> athena7: I'm not sure
[11:29:49 EST(-0500)] <athena7> o
[11:29:50 EST(-0500)] <athena7> k
[11:30:00 EST(-0500)] <athena7> i saw that you had said something about it in nov and wasn't sure
[11:30:33 EST(-0500)] <EricDalquist> I'll try and take a look today
[11:31:05 EST(-0500)] <athena7> thanks
[11:31:14 EST(-0500)] <jlee> athena7: well, it's best practice to do so, because if you have multiple jQuery libraries on the same page, you won't know which one the jQuery object will be pointing to
[11:31:25 EST(-0500)] <athena7> yeah, that's sort of what i figured
[11:31:32 EST(-0500)] <jlee> it's not ABSOLUTELY required, but it avoids headaches down the line
[11:31:39 EST(-0500)] <athena7> does jquery ui work ok with it set on?
[11:32:06 EST(-0500)] <athena7> it sort of seems to
[11:32:09 EST(-0500)] <athena7> less sure about fluid though
[11:32:24 EST(-0500)] <jlee> yep, as long as you follow the order of calling noConflict(extreme) after the jQuery ui files have been sourced
[11:33:13 EST(-0500)] <athena7> so the flow of the page should be something like
[11:33:21 EST(-0500)] <jlee> basically, noConflict(false) renames the '$' object, and noConflict(true) renames both the '$' object and the 'jQuery' object
[11:33:22 EST(-0500)] <athena7> import scripts, javascript code
[11:33:31 EST(-0500)] <athena7> import more scripts, javascript code that uses new version
[11:33:34 EST(-0500)] <athena7> right
[11:33:51 EST(-0500)] <jlee> yep
[11:33:55 EST(-0500)] <athena7> i'm still getting "jQuery is not a function" for one of the calendar widgets
[11:33:59 EST(-0500)] <athena7> and for fluid
[11:35:06 EST(-0500)] <jlee> hmm... is noConflict being calledat the beginning of the javascript code or at the end?
[11:35:46 EST(-0500)] <athena7> beginning
[11:35:47 EST(-0500)] <jlee> depending on how you are using jQuery, it will change when you want to call noConflict
[11:35:53 EST(-0500)] <athena7> ah
[11:36:42 EST(-0500)] <athena7> what would make you need to call it at the end?
[11:37:17 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[11:37:18 EST(-0500)] <jlee> if you don't have everything wrapped in the 'document.ready' event
[11:37:37 EST(-0500)] <athena7> all our stuff should be wrapped in document.ready
[11:38:51 EST(-0500)] <jlee> without looking at the code, what I would say then is to use noConflict at the latest possible moment... it's the easiest route to take...
[11:39:28 EST(-0500)] <jlee> put all your javascript code for the portlet in... and then use noConflict at the very end to "clean up" after itself to make room for future instances of jQuery
[11:41:21 EST(-0500)] <athena7> it can't be after the document.ready statement if i'm going to use jquery there though, right?
[11:43:50 EST(-0500)] <jlee> ah.. I think I see what's going on... in the javascript code, are you mainly using 'jQuery' to use the jquery object – or '$' ?
[11:44:03 EST(-0500)] <jlee> or is it a mix?
[11:44:08 EST(-0500)] <athena7> it's a mix
[11:44:14 EST(-0500)] <athena7> we don't have much code in the page itself though
[11:44:32 EST(-0500)] <athena7> most of it is in another script that uses the (function($){ })(jQuery); style
[11:45:11 EST(-0500)] <jlee> okay.. yeah – that's the proper plugin style and shouldn't break w/ noConflict
[11:45:44 EST(-0500)] <athena7> do i need to include noConflict in those?
[11:46:06 EST(-0500)] <jlee> no, you should only be using one noConflict per jQuery instance
[11:46:51 EST(-0500)] <jlee> so when the jQuery core library is sourced, it creates two global objects.. '$' and 'jQuery'
[11:47:34 EST(-0500)] <jlee> the plugin style above references only the global 'jQuery' object.. any reference to '$' is using the local object reference that is created as a parameter to the function
[11:47:50 EST(-0500)] <athena7> ok, that's what i'd assumed
[11:47:57 EST(-0500)] <athena7> wanted to make sure i wasn't off on that
[11:49:06 EST(-0500)] <jlee> one thing to make sure is that within the other scripts, the only time the jQuery object is references is as a parameter of the self-invoked function...
[11:49:18 EST(-0500)] <jlee> so 'jQuery' shouldn't be anywhere within the body of the function
[11:49:59 EST(-0500)] <jlee> that will cause noConflict to break... you only want to see '$' (local var reference)
[11:51:16 EST(-0500)] <athena7> does this look reasonable? http://uportal.pastebin.com/mf409765
[11:53:45 EST(-0500)] <jlee> yeah, that looks good.. if you are getting an error off of that code snippet, it means that jquery-ui-datepicker-1.6rc4-v1.min.js is using the 'jQuery' object in the body of it's code somewhere... and it shouldn't
[11:53:57 EST(-0500)] * athena7 sighs
[11:53:58 EST(-0500)] <athena7> ok
[11:54:09 EST(-0500)] <athena7> well at least i'm not doing anything wrong then
[11:54:10 EST(-0500)] <jlee> (I've run into that happening on UI code, and have had to submit bug reports)
[11:54:16 EST(-0500)] <athena7> thanks so much for the help
[11:54:25 EST(-0500)] <athena7> i've been tearing my hair out wondering what the problem was
[11:54:26 EST(-0500)] <jlee> so that works w/ extreme turned off?
[11:54:31 EST(-0500)] <athena7> yes
[11:54:42 EST(-0500)] <jlee> yeah, it means they're referencing the jQuery object
[11:54:56 EST(-0500)] <athena7> yeah
[11:54:56 EST(-0500)] <jlee> you could probably do a quick search and replace from 'jQuery' --> '$' and it would fix it
[11:55:30 EST(-0500)] <athena7> maybe i'll try that
[11:55:34 EST(-0500)] <jlee> except of course, you would have to leave the jQuery within the
[11:55:43 EST(-0500)] <jlee> oops.. premature CR
[11:56:03 EST(-0500)] <jlee> you would have to leave 'jQuery' within the parentheses at the very end...
[11:57:16 EST(-0500)] <jlee> the '}(jQuery)' <-- self invoked with the global 'jQuery' object as a parameter, which is then renamed to a local var '$' within the function body
[11:59:02 EST(-0500)] <athena7> shoot
[11:59:13 EST(-0500)] <athena7> it looks like the things that are using jQuery directly are the onclick events
[11:59:45 EST(-0500)] <athena7> so changing them to $ just causes the same error
[12:00:03 EST(-0500)] <jlee> are these onclick events declared within jquery-ui-datepicker-1.6rc4-v1.min.js?
[12:00:07 EST(-0500)] <jlee> or within the main file?
[12:00:19 EST(-0500)] <athena7> within that file, yes
[12:00:35 EST(-0500)] <athena7> things like
[12:00:37 EST(-0500)] <athena7> <a class="ui-datepicker-prev ui-corner-all" onclick="$.datepicker._adjustDate(\'#'inst.id'\', -'stepMonths', \'M\');"'' title="'+prevText'">
[12:00:51 EST(-0500)] <athena7> or rather, jQuery._adjustDate, before i ran search replace
[12:01:41 EST(-0500)] <jlee> doh.. ok, that is really not designed well...
[12:02:02 EST(-0500)] <jlee> yeah, anything within a onclick event within html uses the global namespace
[12:02:08 EST(-0500)] <athena7> yeah
[12:02:12 EST(-0500)] <athena7> pretty lame
[12:02:23 EST(-0500)] <jlee> it would be better to abstract out the javascript there and use unobtrusive js practices...
[12:02:29 EST(-0500)] <athena7> yeah, no kidding
[12:02:39 EST(-0500)] <athena7> i wonder if there's any chance they'd fix that for the 1.6 release
[12:02:41 EST(-0500)] <athena7> i'm guessing now
[12:02:43 EST(-0500)] <athena7> not
[12:06:59 EST(-0500)] <jlee> wow, I took a closer look at that code to see if I could fix it up.. but it's making references to a whole bunch of global variables there... (inst, stepMonths, prevText)... 
[12:07:49 EST(-0500)] <athena7> yeah
[12:07:56 EST(-0500)] <athena7> i'm not quite sure where to go from here
[12:08:20 EST(-0500)] <athena7> the fluid code seems to also reference jQuery, but hopefully i can ask them for help with that
[12:20:35 EST(-0500)] <jlee> actually athena7, on closer look, I think I should be able to patch up datepicker, if you're interested... not sure if it's worth it, if you guys are gonna upgrade to 1.6 when it is released
[12:20:50 EST(-0500)] <jlee> but should take me about 5-10 mins to patch
[12:22:33 EST(-0500)] <EricDalquist> perhaps you guys can patch it and submit that back to the jQuery folks?
[12:23:33 EST(-0500)] <athena7> actually jlee if that's something you don't mind doing, i'd really appreciate it
[12:24:07 EST(-0500)] <athena7> that would also allow us to update the jasig calendar portlet while still letting people using 3.0.x use it
[12:24:30 EST(-0500)] <athena7> and a patch to jQuery sounds like a great idea, since i don't know that they're actually planning to fix this for 1.6
[12:24:33 EST(-0500)] <athena7> they're on rc5 for it already
[12:51:59 EST(-0500)] * athena7 (n=athena7@adsl-99-136-251-32.dsl.wlfrct.sbcglobal.net) has joined ##uportal
[13:23:39 EST(-0500)] * michelled (n=team@142.150.154.197) has joined ##uportal
[13:27:34 EST(-0500)] * colinclark (n=colin@142.150.154.154) has joined ##uportal
[13:37:33 EST(-0500)] <[jlee]> ok, I should have the patch done within a few mins
[13:39:42 EST(-0500)] * athena7 cheers
[13:48:58 EST(-0500)] * colinclark_ (n=colin@142.150.154.101) has joined ##uportal
[13:57:58 EST(-0500)] <[jlee]> uh oh... bad news
[13:59:01 EST(-0500)] <[jlee]> not sure if this is just in rc5 (that is the file I just downloaded)... but there seems to be a whole bunch of onclick handlers created that reference the jQuery global object for td cells (for each of the dates on the calendar..)
[14:00:30 EST(-0500)] <[jlee]> I can still apply the patch for those TD cells... but the patch will be a bit larger than I had thought (if it were just a few of those a tags that needed patching).
[14:04:12 EST(-0500)] <athena7> ugh.
[14:04:23 EST(-0500)] <athena7> it's really kind of disappointing that the code isn't a little more compliant
[14:04:53 EST(-0500)] <EricDalquist> just be glad its OSS and there is a hope the patch will get incorporated into a future release
[14:05:25 EST(-0500)] <athena7> yeah
General
Content
Integrations