[09:07:46 CST(-0600)] <EricDalquist> yay for spending a day just updating jdk and tomcat installs 
[10:42:33 CST(-0600)] <DrewWills> no longer need for hibernateDialect in rdbm.props?
[10:43:30 CST(-0600)] <EricDalquist> not in trunk
[10:43:43 CST(-0600)] <EricDalquist> though we're still fighting with some of the changes hibernate made for large string support
[10:43:51 CST(-0600)] <EricDalquist> don't have a good cross-db solution yet 
[10:43:59 CST(-0600)] <EricDalquist> so you might run into some issues until that gets figured
[10:44:07 CST(-0600)] <EricDalquist> you can see https://forum.hibernate.org/viewtopic.php?f=1&t=1009568 for more info on that
[10:44:49 CST(-0600)] <EricDalquist> so for your patch, athena should take a look too but here are my thoughts from a quick review:
[10:44:57 CST(-0600)] <EricDalquist> I don't think UpdatePreferencesServlet exists anymore
[10:45:20 CST(-0600)] <EricDalquist> StaticRenderingPipeline is gone, you'll need to find the right place in the new rendering pipline
[10:45:32 CST(-0600)] <EricDalquist> though that is related to the in-progress theme/struct attribute refactoring
[10:46:05 CST(-0600)] <EricDalquist> we might want to think about how the subtab stuff integrates with the new URL code
[10:46:18 CST(-0600)] <EricDalquist> not sure how that works yet but this will be a good test case for how to do that
[10:46:35 CST(-0600)] <EricDalquist> those are the primary thoughts
[10:46:43 CST(-0600)] <EricDalquist> you should be able to integrate it without too much work right now
[10:47:05 CST(-0600)] <EricDalquist> the only thing missing is there is no way to set arbitrary theme/struct parameters from the URL right now
[10:47:15 CST(-0600)] <EricDalquist> that should get fixed this weekend
[10:47:31 CST(-0600)] <DrewWills> sounds like it... sounds like the conflict is pretty much the java, which was the simplest bit anyway
[10:47:39 CST(-0600)] <EricDalquist> yeah
[11:33:26 CST(-0600)] <athena> EricDalquist: is the trunk actually-broken or is bamboo just acting up?
[11:33:34 CST(-0600)] <EricDalquist> I'm guessing it is broken
[11:33:39 CST(-0600)] <EricDalquist> it is a compilation error
[11:33:51 CST(-0600)] <athena> where did the log from that go?
[11:33:53 CST(-0600)] <EricDalquist> https://developer.jasig.org/bamboo/browse/UP-TRUNK-JOB1-655/log
[11:33:58 CST(-0600)] <athena> thanks
[11:34:06 CST(-0600)] <EricDalquist> to find it click on the Default Job link in the email then the Log tab
[11:34:12 CST(-0600)] <athena> ok, i'll fix it
[11:34:22 CST(-0600)] <athena> guessing i missed a file or something
[11:34:30 CST(-0600)] <EricDalquist> or actually there is a Logs link on the right side of the email
[11:34:44 CST(-0600)] <athena> ah
[11:34:54 CST(-0600)] <athena> shoulda looked at the email closer rather than goign out ot the site 
[11:35:14 CST(-0600)] <EricDalquist> yeah it's a pain tofind in bamboo
[11:35:44 CST(-0600)] <athena> ok, checking in what i think should be a fix
[11:59:49 CST(-0600)] <EricDalquist> lots of local mods athena?
[12:00:13 CST(-0600)] <athena> heh
[12:00:23 CST(-0600)] <athena> actually somehow i missed changing something in my own environment
[12:00:27 CST(-0600)] <athena> uhhh i don't know how i missed that
[12:00:28 CST(-0600)] * athena sighs
[12:00:30 CST(-0600)] <athena> one of those mornings
[12:00:59 CST(-0600)] <EricDalquist> at least it is a Friday morning
[12:01:06 CST(-0600)] <athena> no kidding!
[12:05:00 CST(-0600)] <athena> so eric i'm having problems running "mvn install" and such from subprojects now
[12:05:07 CST(-0600)] <athena> because the NOTICE plugin complains
[12:05:10 CST(-0600)] <athena> is there something we can do about that?
[12:05:11 CST(-0600)] <EricDalquist> oh uhg
[12:05:29 CST(-0600)] <EricDalquist> um yeah but I'll have to fix the jasig-legal plugin
[12:05:41 CST(-0600)] <EricDalquist> on the short term you can cp the NOTICE and LICENSE files into the subproject
[12:05:51 CST(-0600)] <EricDalquist> I'll see if I can take a look at fixing that
[12:06:09 CST(-0600)] <athena> ok, thanks
[12:11:18 CST(-0600)] <athena> ugh, least that's fixed now
[12:20:38 CST(-0600)] <nickblair> hello everyone
[12:21:37 CST(-0600)] <nickblair> i'm working on a new portlet for UW that displays to a student a google map with markers for the buildings that host their enrolled classes' meetings
[12:22:07 CST(-0600)] <nickblair> i'm trying to use the fluid 2 column layout to display the google map on the left with a list of 'clickable' class names on the right
[12:22:32 CST(-0600)] <nickblair> has anyone had experience using google maps' components in a fluid layout? i'm getting some weird overlapping problems
[12:24:59 CST(-0600)] <nickblair> i'm also hoping to get the left column (for the map) to be a little wider than the column for the class names, and it's not clear how to do that
[12:25:07 CST(-0600)] <nickblair> i end up with equal width columns
[12:48:40 CST(-0600)] <athena> nickblair: i haven't tried google maps w/ FSS, i don't think
[12:48:58 CST(-0600)] <athena> might look at uPortal for some examples on different-width columns
[12:49:15 CST(-0600)] <nickblair> i managed to find a workaround
[12:49:19 CST(-0600)] <athena> oh ok
[12:49:47 CST(-0600)] <nickblair> it involves setting style="width: 75%;" and style="width: 20%;" on the column divs directly :/
[12:49:56 CST(-0600)] <nickblair> is there a fl-col-75?
[12:50:23 CST(-0600)] <nickblair> here's my layout: http://uportal.pastebin.com/VCKTAYmp
[12:51:32 CST(-0600)] <athena> in uportal it looks like it'd be "fl-col-flex75"
[12:52:08 CST(-0600)] <athena> though i think those may be custom classes in uportal
[12:52:17 CST(-0600)] <athena> but that's how our layouts work
[12:55:39 CST(-0600)] <nickblair> yep - that did the trick
[12:55:52 CST(-0600)] <nickblair> fl-col-flex75 and fl-col-flex25
[12:56:00 CST(-0600)] <athena> yay
[12:57:08 CST(-0600)] <nickblair> handy note - if using gmaps api along with jquery, use:
[12:57:09 CST(-0600)] <nickblair> $(window).resize(function() {
[12:57:10 CST(-0600)] <nickblair> google.maps.event.trigger(map, 'resize')
[12:57:10 CST(-0600)] <nickblair> });
[12:57:26 CST(-0600)] <athena> oh! that is a neat trick
[12:57:40 CST(-0600)] <nickblair> where map is the reference to the google.maps.Map
[12:57:42 CST(-0600)] <athena> thanks - maybe need to get that into the portlet in jasig
[12:58:00 CST(-0600)] <nickblair> definitely, map seamlessly resizes with window resize
[12:58:00 CST(-0600)] <athena> by the way, yale contributed code for their google maps portlet that allows search across custom campus locations
[12:58:24 CST(-0600)] <athena> not sure what you're up to, but if there's a chance to re-use that code or collaborate on a campus maps portlet, there's definitely an opportunity to do that
[12:59:13 CST(-0600)] <nickblair> is that in the sandbox?
[12:59:28 CST(-0600)] <athena> i don't think it is yet
[12:59:35 CST(-0600)] <athena> confluence page maybe? hang on
[13:00:10 CST(-0600)] <athena> ah, yes: https://wiki.jasig.org/pages/viewpageattachments.action?pageId=37946242
[13:00:39 CST(-0600)] <athena> is that relevant to anything you're doing?
[13:00:40 CST(-0600)] <nickblair> we recently got access to latitude/longitude data for UW campus buildings, so this was a proof of concept that got promoted quickly
[13:00:46 CST(-0600)] <nickblair> i'll take a peek at what's in there
[13:00:46 CST(-0600)] <athena> oh! that's terrific!
[13:01:02 CST(-0600)] <athena> i've had some specific thoughts about what we might do with that portlet, but haven't had time to implement it
[13:01:17 CST(-0600)] <athena> if you want a demo of that portlet, it's actually on yale's guest page: https://portal.yale.edu
[13:02:11 CST(-0600)] <athena> i think we'd want to create a generic interface for getting building data with probably a default implementation that accepts some sort of standardized XML format?
[13:02:22 CST(-0600)] <athena> we'd probably also want to add some additional fields, like images
[13:03:06 CST(-0600)] <nickblair> here's a screenshot of what I've got so far
[13:03:06 CST(-0600)] <nickblair> https://mywebspace.wisc.edu/npblair/web/temp/classes-map-portlet.png
[13:03:31 CST(-0600)] <athena> ooooh neat
[13:03:37 CST(-0600)] <athena> and actually
[13:03:38 CST(-0600)] <nickblair> and a working prototype where I learned the google maps api: https://mywebspace.wisc.edu/npblair/web/temp/map-example-v3.html
[13:03:48 CST(-0600)] <athena> this relates in an interesting way to the course schedule portlet as well
[13:03:51 CST(-0600)] <nickblair> the items on the right are clickable and open the related marker
[13:03:53 CST(-0600)] <athena> have you looked at that at all?
[13:03:57 CST(-0600)] <nickblair> i have
[13:04:03 CST(-0600)] <athena> that looks really nice so far
[13:04:14 CST(-0600)] <athena> any chance this could be an addition to that portlet?
[13:04:24 CST(-0600)] <athena> i've actually got some outstanding major changes to that, just to let you know
[13:04:37 CST(-0600)] <athena> in particular to make the semester interface more flexible
[13:04:37 CST(-0600)] <nickblair> it potentially could
[13:04:54 CST(-0600)] <athena> i like the toggle bike layer
[13:05:02 CST(-0600)] <athena> got bike directions to UW just yesterday
[13:05:03 CST(-0600)] <nickblair> yeah - that's a one liner in the maps api
[13:05:06 CST(-0600)] <athena> google maps makes me so happy
[13:05:11 CST(-0600)] <athena> as does the maps API
[13:05:14 CST(-0600)] <nickblair> v3 is really slick
[13:05:20 CST(-0600)] <athena> i haven't played with it yet!
[13:05:24 CST(-0600)] <athena> this looks gorgeous though
[13:05:36 CST(-0600)] <athena> if you're willing to share, i think there are a lot of people that would be interested in a portlet like this
[13:08:11 CST(-0600)] <nickblair> we hope to push this out pretty quickly
[13:08:29 CST(-0600)] <athena> neat!
[13:08:55 CST(-0600)] <nickblair> so I'll ask to share this soon afterwards and we can see about consolidating it, CourseSchedulePortlet and yale's content
[13:09:18 CST(-0600)] <athena> that'd be awesome
[13:09:30 CST(-0600)] <athena> it does seem like it touches on both the course schedule portlet and the yale use case
[13:09:42 CST(-0600)] <athena> One Map to Rule Them All!
[13:09:47 CST(-0600)] <nickblair> ha!
[15:55:19 CST(-0600)] Wiki Markup <EricDalquist> hrm ... fluid using the same EL as JSP results in fun JSPs: ${'${'}*.docId}
[15:55:52 CST(-0600)] <colinclark> That's some serious EL escaping
[15:56:30 CST(-0600)] <athena> yeah
[15:56:38 CST(-0600)] <athena> there are plenty of examples of it in uportal by now
[15:56:50 CST(-0600)] <athena> and uhhhh i just copy paste, because it gives me a headache
[15:56:53 CST(-0600)] <EricDalquist>
[15:56:55 CST(-0600)] <EricDalquist> yeah
[15:57:18 CST(-0600)] <EricDalquist> for only being 7 chars getting a ${ to print out in JSTL sure hurts the head
[15:57:22 CST(-0600)] <athena> like target: removeUrl.replace("PORTLETID", '${"${*.id}"}'),
[15:57:31 CST(-0600)] <athena> no kidding
[15:57:45 CST(-0600)] <EricDalquist> maybe we can do a Fluid feature request
[15:57:51 CST(-0600)] <EricDalquist> make the start/end exp configurable
[15:57:58 CST(-0600)] <EricDalquist> so we can do #{} for fluid
[15:58:08 CST(-0600)] <athena> until somehow that conflicts w/ spring el
[15:58:27 CST(-0600)] <colinclark> That may actually already be configurable, athena
[15:58:42 CST(-0600)] <athena> that'd be kinda cool
[15:58:50 CST(-0600)] <colinclark> You'd have to ping Bosmon, but it was in the early versions of IoC embedded in Fluid Engage
[16:00:54 CST(-0600)] <EricDalquist> hrm
[16:00:57 CST(-0600)] <athena> neat!
[16:01:06 CST(-0600)] * athena still needs to find out more about the whole IoC thing
[16:01:22 CST(-0600)] <EricDalquist> off to bug bosmon in #fluid ...
[16:01:38 CST(-0600)] <athena> by the way, colinclark, i know you guys are really busy with releasing, but i don't know if you might have a few minutes at some point to close that mobile skinning loop
[16:01:49 CST(-0600)] <colinclark> oh yes
[16:01:55 CST(-0600)] <colinclark> mobile skinning
[16:02:05 CST(-0600)] <athena> think we're pretty close to the point where i'd like to have some recommendations to share with the uportal dev lists - want to make sure we can get stuff together in time for the next up release
[16:02:06 CST(-0600)] <athena> yes
[16:02:09 CST(-0600)] <colinclark> let me push this last set of 1.3.1 blocker fixes up to github
[16:02:12 CST(-0600)] <colinclark> and then i'll re-read your email
[16:02:15 CST(-0600)] <colinclark> and then we can discuss here
[16:02:17 CST(-0600)] <colinclark>
[16:02:17 CST(-0600)] <athena> oh awesome! thanks so much
[16:02:25 CST(-0600)] <athena> i know you guys are busy - really appreciate it
[16:03:00 CST(-0600)] <colinclark> no worries
[16:04:27 CST(-0600)] <colinclark> hey, so I got an exciting email from gary thompson yesterday
[16:04:34 CST(-0600)] <colinclark> he's contributing some fixes to FSS for 1.4
[16:04:38 CST(-0600)] <colinclark> including portlet styles
[16:07:01 CST(-0600)] <athena> yeah
[16:07:13 CST(-0600)] <colinclark> athena: Okay, I re-read your email
[16:07:15 CST(-0600)] <athena> cooperative development effort - really glad we can devote some time to that
[16:07:19 CST(-0600)] <colinclark> It's really great
[16:08:02 CST(-0600)] <athena> i've got mixed feelings about jquery mobile - it's really shiny, but it's also pretty heavyweight
[16:08:23 CST(-0600)] <athena> put together some test stuff for uportal - i suspect we'd need to work some issues in a portal environment
[16:08:43 CST(-0600)] <colinclark> Yeah
[16:08:45 CST(-0600)] <colinclark> I share your concerns
[16:08:47 CST(-0600)] <athena> do you guys have thoughts about where you see the dividing line between jQuery and fluid for mobile in the future?
[16:08:59 CST(-0600)] <colinclark> I don't, yet
[16:09:10 CST(-0600)] <colinclark> I haven't had much time to look closely at it
[16:09:20 CST(-0600)] <colinclark> Here's what I can tell you, from a strategic perspective
[16:09:21 CST(-0600)] <athena> jquery mobile seems pretty heavily js-driven
[16:09:35 CST(-0600)] <colinclark> We're not going to compete with jQM full-on as a mobile toolkit
[16:09:42 CST(-0600)] <colinclark> we'd never win, and it wouldn't be productive
[16:09:51 CST(-0600)] <colinclark> on the other hand, Fluid does some things in a unique way
[16:10:09 CST(-0600)] <colinclark> DOM agnosticism, totally unobtrusive markup, and portal-friendliness
[16:10:19 CST(-0600)] <colinclark> jQM will always mix up CSS and JS into a single package
[16:10:31 CST(-0600)] <colinclark> makes it easy in that jQuery "drop it in and go" sort of way
[16:10:41 CST(-0600)] <colinclark> but as you say, risks of weird markup, flicker, and conflicts
[16:10:47 CST(-0600)] <athena> where easy covers the use cases they've thought about, anyway
[16:10:48 CST(-0600)] <athena> yeah
[16:11:05 CST(-0600)] <athena> it's hard - we like the fluid way of doing things much better
[16:11:08 CST(-0600)] <colinclark> I see our unique niche in mobile as enabling easy deployment of UIs on both full-browser and mobile
[16:11:16 CST(-0600)] <colinclark> So I think that the mFSS has a long future
[16:11:17 CST(-0600)] <athena> but at the same time i think we really need some of the capabilities they're offering right now
[16:11:21 CST(-0600)] <colinclark> yep
[16:11:32 CST(-0600)] <colinclark> We're not going to have a ton of resources to dedicate to mobile for a bit
[16:11:43 CST(-0600)] <colinclark> It's on the list, it's definitely something we'll keep working on
[16:11:58 CST(-0600)] <colinclark> I want to make it easy for developers to reuse as much code as possible when deploying on mobile
[16:12:11 CST(-0600)] <athena> in the long run would you see mFSS running in the same page as jQM?
[16:12:11 CST(-0600)] <colinclark> We all know that good mobile sites involve uniquely mobile-y designs
[16:12:35 CST(-0600)] <colinclark> but on the other hand, at this point it's like you have to pay the coding effort of two completely different sites to support both mobile and full web
[16:12:50 CST(-0600)] <colinclark> So mFSS and full FSS are largely interchangeable
[16:13:19 CST(-0600)] <colinclark> in the long run I want to make that much more ubiquitous, and then create tools on both client and server that can help deliver alternative version of a UI or strip a page down to a simpler form for mobile
[16:13:29 CST(-0600)] <colinclark> So yes, I'd like to see mFSS running alongside jQM as needed
[16:13:57 CST(-0600)] <athena> sounds like a great future
[16:14:12 CST(-0600)] <colinclark> So I'm just thinking through your options
[16:14:27 CST(-0600)] <colinclark> I guess you could put some pressure on improvements to mFSS, and we'd try to respond
[16:15:01 CST(-0600)] <colinclark> You could help, etc.
[16:15:16 CST(-0600)] <colinclark> Alternatively, you could work with jQM for awhile, find out what it's good for and less good for
[16:15:22 CST(-0600)] <colinclark> and then we could try to fill the gaps wherever possible
[16:15:38 CST(-0600)] <athena> makes sense
[16:15:48 CST(-0600)] <athena> i think we absolutely have to adopt jQM at least for obvious stuff like events
[16:15:58 CST(-0600)] <colinclark> yep, that's probably right
[16:16:25 CST(-0600)] <colinclark> I guess I can give you more concrete answers when I get some time to sit down with jQM and write some code
[16:16:27 CST(-0600)] <athena> clearly we'll want to use things like the tap, swipe, etc. - that's cool stuff and it's obvious that those should function like jQuery events
[16:16:30 CST(-0600)] <colinclark> yep
[16:16:38 CST(-0600)] <colinclark> that makes tons of sense to me
[16:17:05 CST(-0600)] <athena> i suspect that in the short term we might want to at least experiment with some of their CSS stuff just because it'll take less time to develop something highly demoable
[16:17:11 CST(-0600)] <colinclark> yep, I agree
[16:17:17 CST(-0600)] <athena> but in the long term i think we'd really prefer a pure-CSS framework
[16:17:18 CST(-0600)] <colinclark> It's better to have something than virtually nothing
[16:17:32 CST(-0600)] <colinclark> So, FLOE is the project that is pushing our priorities on Infusion most right now
[16:17:37 CST(-0600)] <athena> well i wouldn't call what we have now virtually nothing
[16:17:37 CST(-0600)] <colinclark> and luckily it all ties in nicely with this
[16:17:46 CST(-0600)] <colinclark>
[16:18:01 CST(-0600)] <athena> but it's nice that jQM has had the opportunity to implement support for more than webkit browsers
[16:18:16 CST(-0600)] <colinclark> yep
[16:18:22 CST(-0600)] <colinclark> I'm really, really impressed with their browser coverage
[16:18:25 CST(-0600)] <colinclark> they got it right
[16:18:36 CST(-0600)] <colinclark> not just the "oh, everyone uses webkit" thing that we all fall into
[16:18:43 CST(-0600)] <athena> so it sounds like it'd maybe be reasonable to do some work with jQM, but keep you guys in the loop and figure out where we can all work together to add to what they havne't prioritized?
[16:18:55 CST(-0600)] <colinclark> That makes a lot of sense to me, athena
[16:19:01 CST(-0600)] <athena> ok
[16:19:14 CST(-0600)] <colinclark> You can suss out what is great and not so great, and we can try to do the rest
[16:19:22 CST(-0600)] <athena> wanted to make sure we're thinking about paths that don't preclude us from continuing to work with you all
[16:19:31 CST(-0600)] <colinclark> I've never had a good response from the Filament Group, but I still feel like they'd be amenable to working with us
[16:19:41 CST(-0600)] <athena> and definitely don't want you to think that we're not still committed to using fluid technology in uportal
[16:19:50 CST(-0600)] <colinclark> so we might be able to get some stuff upstream, too, like we have with jQuery UI
[16:20:12 CST(-0600)] <colinclark> athena: I have no doubt about it, no worries
[16:20:20 CST(-0600)] <athena> ok, good
[16:20:30 CST(-0600)] <athena> we've really gotten a huge amount of value from fluid and i don't see that changing
[16:20:35 CST(-0600)] <colinclark> cool
[16:20:45 CST(-0600)] <colinclark> As I say, I don't want to compete with with jQuery Mobile anyway
[16:20:49 CST(-0600)] <athena> in fact, i think we now have the last of our custom js converted to fluid components
[16:20:50 CST(-0600)] <colinclark> they're doing awesome stuff
[16:21:08 CST(-0600)] <athena> right - good to work with other open source projects, have everyone concentrate on working together rather than duplicating efforts
[16:23:09 CST(-0600)] <colinclark> yep, exactly
[16:23:33 CST(-0600)] <athena> thanks for the input i really appreciate it
[16:23:41 CST(-0600)] <colinclark> no problem
[16:23:42 CST(-0600)] <colinclark> it's fun
[16:24:03 CST(-0600)] <EricDalquist> oh before you g colinclark any recommendations for a JavaScript IDE?
[16:24:19 CST(-0600)] <colinclark> People seem to like Aptana a lot
[16:24:28 CST(-0600)] <colinclark> Though the Eclipse plugin isn't great
[16:24:31 CST(-0600)] <colinclark> most people use the standalone Aptana
[16:24:33 CST(-0600)] <EricDalquist> ok
[16:24:35 CST(-0600)] <colinclark> I don't care for it much
[16:24:44 CST(-0600)] <colinclark> but I've sort of reverted to the dark ages of IDEs
[16:24:51 CST(-0600)] <colinclark> Git on the command line and TextMate for basic editing
[16:25:02 CST(-0600)] <colinclark> I really, really miss the good tooling support in Java some days 
[16:25:05 CST(-0600)] <colinclark> You guys are lucky
[16:25:12 CST(-0600)] <EricDalquist> I'm just doing a bunch of JS work and I really mis all the nice things I get for Java in eclipse
[16:25:23 CST(-0600)] <EricDalquist> like even a basic navigation outline of the JS would be nice
[16:25:44 CST(-0600)] <EricDalquist> amazingly we still have some devs here doing java work in vim/emacs
[16:25:57 CST(-0600)] <athena> i tend to use eclipse and textmate
[16:26:04 CST(-0600)] <EricDalquist> I couldn't deal with all the code navigation features
[16:26:10 CST(-0600)] <athena> sometimes eclipse shows the method outline
[16:26:22 CST(-0600)] <athena> i think the closures screw it up though?
[16:26:43 CST(-0600)] <EricDalquist> yeah
[16:26:52 CST(-0600)] <athena> it's still somewhat useful though
[16:27:10 CST(-0600)] <athena> like if i open up up-layout-gallery it at least lists the fluid components
[16:27:14 CST(-0600)] <athena> that's about it though
[16:27:29 CST(-0600)] <athena> i've found that the closures make some of the unit testing options difficult as well
[16:34:45 CST(-0600)] <athena> EricDalquist: how would you feel about me updating the mobile theme in trunk to an experimental version that uses jQuery Mobile?
[16:34:59 CST(-0600)] <athena> if it doesn't work out we could always revert to the previous version
[16:35:05 CST(-0600)] <EricDalquist> fine by me
[16:35:07 CST(-0600)] <athena> ok
[16:35:25 CST(-0600)] <athena> hopefully that would give us an opportunity to try it out and see what we all think
[16:35:43 CST(-0600)] <athena> figure out which pieces we can live with, and which maybe don't work well in a portal environment
[16:38:04 CST(-0600)] <athena> wow i think we're close to having a usable permissions portlet
[16:40:32 CST(-0600)] <athena> having some of gary's time has made a big difference
[17:20:55 CST(-0600)] <DrewWills> HOW DOES MESSAGES.XSL WORK IN TRUNK?
[17:21:01 CST(-0600)] <DrewWills> er, oops caps
[17:21:06 CST(-0600)] <athena> zomg
[17:21:11 CST(-0600)] <athena> it does not work in trunk
[17:21:15 CST(-0600)] <athena> so i guess we should remove it
[17:21:28 CST(-0600)] <athena> or at least, i think we've migrated all the messages out of it at this point - would be good to double check that
[17:21:31 CST(-0600)] <DrewWills> i suppose we should
[17:22:37 CST(-0600)] <DrewWills> i suppose all those strings have been moved to the resource bundles... how do you reference those values?
[17:23:39 CST(-0600)] <athena> ah! there's a xalan helper
[17:23:54 CST(-0600)] <athena> i still haven't completed the work of making that do HTML, but it's fine for simple string messages
[17:24:24 CST(-0600)] <athena> here's an example:
[17:24:26 CST(-0600)] Wiki Markup <athena> <a href="#mainNavigation" title="{upMsg:getMessage('skip.to.page.navigation', $USER_LANG)}" id="skipToNav" accesskey="N">
[17:24:35 CST(-0600)] <athena> so you feed it the message key and the $USER_LANG variable
[17:24:47 CST(-0600)] <athena> works like the auth ones we've had for a while
[17:24:50 CST(-0600)] Wiki Markup <DrewWills> {upMsg:getMessage('add.tab', $USER_LANG)}
[17:24:56 CST(-0600)] <athena> yep!
[17:24:57 CST(-0600)] <DrewWills> yeah found one
[17:25:06 CST(-0600)] <athena> that look like it'll work for you right now?
[17:25:52 CST(-0600)] <DrewWills> oh definately... and it's an improvement, moving them there
[17:25:58 CST(-0600)] <athena> awesome
[17:26:21 CST(-0600)] <athena> think we're getting close to having most content migrated out
[17:26:29 CST(-0600)] <DrewWills> just need a display label for the default tabgroup... going with "More"
[17:37:57 CST(-0600)] <DrewWills> that syntax doesn't appear to work inside an <xsl:value-of/>
[17:38:14 CST(-0600)] <athena> what do you have right now?
[17:39:34 CST(-0600)] <DrewWills> oh i'm being silly... doing too many things at once
[17:39:46 CST(-0600)] <athena> i so hear that
[17:39:57 CST(-0600)] <athena> kris asked me what was wrong today and i just said "brain-melt"
[17:40:03 CST(-0600)] <DrewWills> i put the dang {}s around it
[17:40:18 CST(-0600)] <athena> yeah i forget that too sometimes
[17:40:20 CST(-0600)] <athena> oh well!
[17:54:47 CST(-0600)] <DrewWills> this one is new to me... any tips?
[17:54:48 CST(-0600)] <DrewWills> ERROR [http-8080-6] Feb/18 16:53:28,855 def.AbstractFlushingEventListener.[] - Could not synchronize database state with session
[17:54:48 CST(-0600)] <DrewWills> org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch update
[17:58:29 CST(-0600)] <athena> what database do you use?
[17:59:13 CST(-0600)] <DrewWills> HSQL of course
[18:00:14 CST(-0600)] <athena> hm ok
[18:00:21 CST(-0600)] <DrewWills> not sure of the impact of the issue... but discovered this link let's me in: http://localhost:8080/uPortal/Login?userName=admin&password=admin
[18:00:46 CST(-0600)] <athena> have you deleted the db and run a clean build since the JPA2 update?
[18:00:59 CST(-0600)] <DrewWills> yeah, earlier today
[18:01:03 CST(-0600)] <athena> oh weird
[18:01:08 CST(-0600)] <athena> i don't know then
[18:01:12 CST(-0600)] <athena> i think eric uses hsql too?
[18:02:08 CST(-0600)] <DrewWills> i trust it will get sorted... just need to get in
[18:02:35 CST(-0600)] <athena> yeah
[18:02:52 CST(-0600)] <athena> i ahve to admit i pretty much always just use that direct login url
[18:02:54 CST(-0600)] * athena is lazy
Page Comparison
General
Content
Integrations