[02:56:29 EDT(-0400)] <higpetter> where is org.jasig.portal.services.persondir.support.LdapPersonAttributeDaoImpl ???
[03:32:15 EDT(-0400)] <higpetter> oko, that one's without Imp,
[03:33:25 EDT(-0400)] <higpetter> but why does ant/maven/cernunnos/whatever forget about the downloaded jars in the repository all the time?
[03:33:53 EDT(-0400)] <higpetter> I have to make 'ant clean' every now and then to make it know what jars it has...
[07:41:28 EDT(-0400)] * michelled (n=team@142.150.154.197) has joined ##uportal
[08:10:53 EDT(-0400)] * rolfm (n=rolfm@cpe-24-31-170-6.columbus.res.rr.com) has joined ##uportal
[08:19:56 EDT(-0400)] * EricDalquist (n=EricDalq@adsl-76-208-67-245.dsl.mdsnwi.sbcglobal.net) has joined ##uportal
[08:37:00 EDT(-0400)] * EricDalquist (n=EricDalq@adsl-76-208-67-245.dsl.mdsnwi.sbcglobal.net) has joined ##uportal
[08:46:58 EDT(-0400)] <athena7> higpetter: if you're working with uPortal 3, the ldap attribute dao implementation moved to a standalone project
[08:47:10 EDT(-0400)] <athena7> there's a not about it in the up3 manual - http://www.ja-sig.org/wiki/display/UPM30/02+Converting+personDirectory.xml
[08:47:16 EDT(-0400)] <athena7> brb
[08:47:17 EDT(-0400)] <higpetter> athena7: I found out...
[08:47:31 EDT(-0400)] * athena7 (n=athena7@75.58.126.207) has joined ##uportal
[08:48:29 EDT(-0400)] <higpetter> athena7: I found out...
[08:48:47 EDT(-0400)] <higpetter> just started trying up3
[08:53:21 EDT(-0400)] <higpetter> the bigger problem is that maven forgets to much of what it has downloaded...
[08:53:40 EDT(-0400)] <higpetter> lika a build only works if it's built from "clean" state
[08:53:51 EDT(-0400)] <higpetter> ..when it still remembers what it has downloaded
[08:55:23 EDT(-0400)] * fulekia (n=fulekia@140.141.213.238) has joined ##uportal
[09:03:15 EDT(-0400)] * fulekia (n=fulekia@140.141.213.238) has joined ##uportal
[09:43:36 EDT(-0400)] * colinclark (n=colin@bas1-toronto09-1279475053.dsl.bell.ca) has joined ##uportal
[09:59:44 EDT(-0400)] * uwnick (n=nblair@boost.doit.wisc.edu) has joined ##uportal
[10:06:13 EDT(-0400)] * EricDalquist (n=EricDalq@static-210-59.vpn.wisc.edu) has joined ##uportal
[10:10:54 EDT(-0400)] * apetro (n=apetro@72.33.23.236) has joined ##uportal
[10:21:01 EDT(-0400)] <apetro> In Pyle 205 with EricDalquist, uwnick, Jim Helwig, Mary Hunt, Anastasia Cheetham, and Allison Bloodworth
[10:21:43 EDT(-0400)] <apetro> I'm trying to make use of Fluid Inline Edit in the AjaxNotepadPortlet as an exercise in using a Fluid component, now that I have that portlet at least rendering.
[10:23:41 EDT(-0400)] <athena7> oh nice!!
[10:23:43 EDT(-0400)] <athena7> that'd be great
[10:24:14 EDT(-0400)] * jessm (n=Jess@c-76-19-199-61.hsd1.ma.comcast.net) has joined ##uportal
[10:28:54 EDT(-0400)] * fulekia (n=fulekia@wso-mbp15.test.denison.edu) has joined ##uportal
[10:36:38 EDT(-0400)] <apetro> eh. I doubt I'll get it to the point where it's attractive to adopt out of the box, but it could be a working example for AJAX-inclined portlet developers
[10:40:30 EDT(-0400)] <athena7> yes, i think that portlet could be a very useful example
[10:40:52 EDT(-0400)] <athena7> by the way, which version of uportal are you developing the portlet with?
[10:43:11 EDT(-0400)] <apetro> 3.1.0 M1
[10:43:31 EDT(-0400)] <apetro> for no good reason other than I had it handy and it seems to be working
[10:43:43 EDT(-0400)] <apetro> all the change so far is at the portlet level
[10:48:53 EDT(-0400)] <athena7> ok
[10:49:16 EDT(-0400)] <athena7> just as an FYI, the portal includes some of the fluid code, but not the inline editor
[10:49:26 EDT(-0400)] <apetro> k
[10:49:57 EDT(-0400)] <athena7> there's a description in a text file of what parts of the fluid 0.5 release are included
[10:50:14 EDT(-0400)] <athena7> so you can look at the fluid documentation and include in your portlet whichever files aren't included by the portal itself
[10:50:17 EDT(-0400)] <apetro> right now the approach is to copy into the AjaxNotepadPortlet its very own copy of Fluid (and dependencies!) but yeah, depending on a portal-provided Fluid seems the better way to go
[10:50:42 EDT(-0400)] <athena7> well, there are some problems with including some jquery components twice in the same page
[10:51:19 EDT(-0400)] <athena7> everything just kind of stops working
[10:51:33 EDT(-0400)] <apetro> k. I'll see how soon I can run into that.
[10:51:46 EDT(-0400)] <athena7> so i'd particularly try and avoid including dependencies twice
[10:51:47 EDT(-0400)] <athena7> lol 
[10:51:48 EDT(-0400)] <athena7> good luck!
[10:52:56 EDT(-0400)] * jessm (n=Jess@c-76-19-199-61.hsd1.ma.comcast.net) has joined ##uportal
[10:54:59 EDT(-0400)] <apetro> would uPortal deploy with the Fluid .war deploying alongside it as another webapp?
[10:55:29 EDT(-0400)] <apetro> that seems attractive in minimizing the uPortal-specificness of the portlet's depending on a uPortal-provided Fluid
[10:57:19 EDT(-0400)] <apetro> (Pyle-local discussion with Eric suggests that depending on the .war Fluid form factor is attractive)
[10:59:37 EDT(-0400)] <athena7> i think we do want a uportal-specific fluid, though
[10:59:54 EDT(-0400)] <EricDalquist> do we need to customize the fluid JS?
[11:00:13 EDT(-0400)] <athena7> we'll have to short term if we need to add the jquery selectables back in
[11:00:18 EDT(-0400)] <athena7> because there's a namespace conflict
[11:00:29 EDT(-0400)] <athena7> i took the jquery component out for the time being since we weren't using it anyway
[11:00:59 EDT(-0400)] <athena7> but there's an open question of how we deal with the tension between making everything available, and keeping the required javascript small
[11:01:12 EDT(-0400)] <athena7> if we want to keep it small, then we need to package just the files that are actually required
[11:01:19 EDT(-0400)] <EricDalquist> true
[11:01:25 EDT(-0400)] <athena7> which means it makes sense to have a portal-specific distribution
[11:01:30 EDT(-0400)] <EricDalquist> another approach is to contribute some code to fluid
[11:01:42 EDT(-0400)] <EricDalquist> to expose the JS through a servlet that sets very good caching headers
[11:01:54 EDT(-0400)] <EricDalquist> which helps fix the namespacing issue
[11:01:57 EDT(-0400)] <EricDalquist> er
[11:01:59 EDT(-0400)] <EricDalquist> sorry
[11:02:00 EDT(-0400)] <athena7> also that way we can combine them all into one file to keep requests down, etc.
[11:02:01 EDT(-0400)] <EricDalquist> the size issue
[11:02:04 EDT(-0400)] <EricDalquist> yeah
[11:02:15 EDT(-0400)] <athena7> caching is good, but the size does still matter
[11:02:31 EDT(-0400)] <athena7> i bundled jquery and fluid in their own directories, with versioned file names
[11:02:39 EDT(-0400)] <EricDalquist> so if we can help Fluid out there I think I'd really like to see that approach if we can get there
[11:02:49 EDT(-0400)] <athena7> so people should now be able to set perma-caching type stuff on those directories safely with apache or whatever now, if they wanted
[11:03:03 EDT(-0400)] <EricDalquist> where we can just depend on the Fluid WAR from the uPortal EAR
[11:03:10 EDT(-0400)] <EricDalquist> and not have to do any mods to it
[11:03:47 EDT(-0400)] <athena7> well, normally we shouldn't have to do mods, other than things like selecting the right files
[11:03:59 EDT(-0400)] <athena7> there seemed to be a push to combine things too, to keep the http requests down
[11:05:25 EDT(-0400)] <EricDalquist> yeah
[11:05:59 EDT(-0400)] <athena7> one thing to remember about caching too is i think some people have found that javascript often doesn't get cached when it's served up over SSL
[11:06:03 EDT(-0400)] <athena7> which is probably most portal installations
[11:06:32 EDT(-0400)] <athena7> so even if we set cache headers, file size will probably still be an issue
[11:06:41 EDT(-0400)] <apetro> (EricDalquist and Anastasia Cheetham are discussing)
[11:06:48 EDT(-0400)] <athena7> gotcha
[11:06:58 EDT(-0400)] <athena7> i don't think it's really a fluid problem, although they may have useful insight
[11:07:02 EDT(-0400)] <athena7> it's a jquery problem too
[11:07:08 EDT(-0400)] <athena7> and any other dependencies we have
[11:07:40 EDT(-0400)] <athena7> i think we have more flexibility if we include the fluid code in the portal, because we can potentially do magic w/ the yui compressor plugin
[11:07:45 EDT(-0400)] <athena7> for example, we could tell people
[11:08:02 EDT(-0400)] <athena7> ok, here's the directory where all the fluid code goes. you want more fluid code in your base portal, add it here
[11:08:21 EDT(-0400)] <athena7> it'll all get concat'd together and minified by the build, automatically
[11:08:40 EDT(-0400)] <athena7> of course, if you do that, then setting permanent caching is a bad idea, because the contents of that combined file might change
[11:09:31 EDT(-0400)] <EricDalquist> so to summarize the real world talk we just had
[11:09:46 EDT(-0400)] <EricDalquist> one idea is a slightly smart JS serving servlet
[11:10:04 EDT(-0400)] <EricDalquist> you can parameterize it with fluid component names
[11:10:23 EDT(-0400)] <EricDalquist> which gives it a unique URL depending on what you want
[11:10:38 EDT(-0400)] <athena7> that sounds like a pretty reasonable approach
[11:10:43 EDT(-0400)] <EricDalquist> the servlet builds the appropriate JS, minifies it, sets the caching headers and gzips it on the way out
[11:10:54 EDT(-0400)] <EricDalquist> I don't think the servlet would be all that complex
[11:10:55 EDT(-0400)] <athena7> that'd be great, i like that approach
[11:10:58 EDT(-0400)] <athena7> no
[11:11:05 EDT(-0400)] <EricDalquist> and would let people easily 'add' new components
[11:11:08 EDT(-0400)] <athena7> yes
[11:11:25 EDT(-0400)] <EricDalquist> and it sounds like Fluid would be more than happy to include something like that (if we wrote it for them)
[11:11:26 EDT(-0400)] <athena7> we'd want the version number as part of the URL, too
[11:11:28 EDT(-0400)] <EricDalquist> yes
[11:11:31 EDT(-0400)] <jessm>
[11:11:34 EDT(-0400)] <athena7> yeah, that'd be great
[11:11:35 EDT(-0400)] <EricDalquist> which the servlet can help enforce
[11:11:52 EDT(-0400)] <athena7> we could do that with jquery, jqueryui, and fluid
[11:11:55 EDT(-0400)] <EricDalquist> you could even in theory package multiple versions of fluid in a single webapp
[11:11:56 EDT(-0400)] <athena7> i like that plan very much
[11:11:58 EDT(-0400)] <EricDalquist> yup
[11:12:07 EDT(-0400)] <EricDalquist> your URL may get kind of complex
[11:12:17 EDT(-0400)] <EricDalquist> but I don't think that is too big of an issue
[11:12:37 EDT(-0400)] <athena7> i think that's fine
[11:12:45 EDT(-0400)] <EricDalquist> the hardest part will likely be enumarating the dependencies between fluid components and jquery
[11:12:52 EDT(-0400)] <athena7> i like this approach, because it's flexible, and i think it helps avoid people shooting themselves in the foot
[11:12:56 EDT(-0400)] <athena7> yes
[11:12:59 EDT(-0400)] <EricDalquist> yeah
[11:13:14 EDT(-0400)] <EricDalquist> customization without actually letting them muck with JS files
[11:13:37 EDT(-0400)] <athena7> sounds great
[11:14:37 EDT(-0400)] * anastasiac (n=stasia@72.33.23.226) has joined ##uportal
[11:14:48 EDT(-0400)] <EricDalquist> now who is going to write it? 
[11:17:23 EDT(-0400)] * Bosmon (n=Antranig@ginger.caret.cam.ac.uk) has joined ##uportal
[11:21:21 EDT(-0400)] <EricDalquist> apetro and I are just talking that this is really just Maven
[11:21:31 EDT(-0400)] <EricDalquist> with the compile step replaced by minification
[11:21:44 EDT(-0400)] <EricDalquist> so we may honestly want to look at what the Maven Embedder APIs provide
[11:21:55 EDT(-0400)] <EricDalquist> so we don't write our own dependency graph traversal algorithm
General
Content
Integrations