Page Comparison

[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
[11:23:05 EDT(-0400)] <athena7> hang on, phone call
[11:23:10 EDT(-0400)] <athena7> sorry
[11:25:42 EDT(-0400)] * holdorph (n=holdorph@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[11:28:49 EDT(-0400)] <athena7> ok, back
[11:30:02 EDT(-0400)] <athena7> i don' really know anything about the embedder apis
[11:30:07 EDT(-0400)] <apetro> It's a serious idea, but I'm also quite entertained by the thought of a servlet that's backed by invoking Maven to compose the response to the request for JavaScript
[11:30:08 EDT(-0400)] <athena7> and i don't know who's going to write it either
[11:30:18 EDT(-0400)] <athena7> i'm completely overbooked through the end of the month, at least
[11:31:41 EDT(-0400)] <apetro> it may be a legitimate idea for the Unicon Coop Dev queue. Folks asking about richness and JavaScript in portlets all the time.
[11:32:44 EDT(-0400)] <athena7> sounds fair
[11:32:51 EDT(-0400)] <athena7> very much something i'd be interested in working on
[11:32:59 EDT(-0400)] <athena7> but unlikely to happen next week
[11:33:11 EDT(-0400)] <athena7> and will be leaving for honeymoon after that
[11:33:20 EDT(-0400)] <EricDalquist> something we just need to keep in mind and add some docs about
[11:33:57 EDT(-0400)] <athena7> yeah
[11:34:02 EDT(-0400)] <athena7> make a jira for it?
[11:34:14 EDT(-0400)] <Bosmon> There is nothing entertaining about the idea of a servlet backed by Maven
[11:34:27 EDT(-0400)] <EricDalquist> lol
[11:34:34 EDT(-0400)] <athena7> i don't know if we really need to use maven, to be honest
[11:34:48 EDT(-0400)] <athena7> we can probably just write it to the yui compressor API?
[11:34:59 EDT(-0400)] <athena7> i'm not sure that maven actually adds value
[11:35:06 EDT(-0400)] <EricDalquist> I guess it just depends on how complex the dependency resolution is
[11:35:24 EDT(-0400)] <EricDalquist> aka Fluid component X depends on jQuery A, B & C
[11:35:34 EDT(-0400)] <EricDalquist> if we just have one level
[11:35:37 EDT(-0400)] <EricDalquist> thats pretty easy
[11:35:42 EDT(-0400)] <EricDalquist> if it gets more complex than that ....
[11:35:47 EDT(-0400)] <athena7> is there some way to reference the flow id from a spring webflow xml file?
[11:36:00 EDT(-0400)] <athena7> ok, i see what you mean
[11:36:09 EDT(-0400)] <EricDalquist> what are you trying to do with the flow?
[11:36:37 EDT(-0400)] <athena7> get the flow execution key out so i can hand it off to a method
[11:37:04 EDT(-0400)] <EricDalquist> no idea ... what does a method need the flow execution key for?
[11:37:10 EDT(-0400)] <athena7> validate a captcha
[11:37:14 EDT(-0400)] <EricDalquist> ah
[11:37:23 EDT(-0400)] <athena7> i was actually thinking we'd just have all the desired files in the url
[11:37:33 EDT(-0400)] <athena7> not specify one thing and have it determine dependencies
[11:37:43 EDT(-0400)] <athena7> because there may be times you actually don't want every dependency
[11:37:47 EDT(-0400)] <EricDalquist> yup
[11:37:57 EDT(-0400)] <EricDalquist> and if there is ever more than one level of dependencies
[11:38:05 EDT(-0400)] <EricDalquist> it gets really complex quite fast
[11:38:16 EDT(-0400)] <athena7> for example, you might include the reorderer and all it's dependencies in the portal
[11:38:23 EDT(-0400)] <EricDalquist> yup
[11:38:35 EDT(-0400)] <athena7> and then for logged in users you want an additional piece
[11:38:43 EDT(-0400)] <athena7> but don't want to include everything else twice
[11:38:51 EDT(-0400)] <athena7> so you'd actually be including two urls
[11:39:01 EDT(-0400)] <athena7> the first of which should have dependencies, and the second of which shouldn't
[11:39:11 EDT(-0400)] * dstn (n=dstn@unaffiliated/dstn) has joined ##uportal
[11:39:19 EDT(-0400)] <athena7> which is why i'd kind of assumed we'd really just enumerate every file
[11:39:25 EDT(-0400)] <EricDalquist> well
[11:39:35 EDT(-0400)] <EricDalquist> I think you'd just have two different URLs
[11:39:45 EDT(-0400)] <EricDalquist> and each does everything
[11:39:49 EDT(-0400)] <dstn> afternoon
[11:39:52 EDT(-0400)] <athena7> hi dstn
[11:39:56 EDT(-0400)] <athena7> what do you mean by everything?
[11:39:56 EDT(-0400)] <EricDalquist> dstn: where are you?
[11:40:09 EDT(-0400)] <EricDalquist> well everything
[11:40:29 EDT(-0400)] <athena7> ok, but then you'd wind up including things twice
[11:40:36 EDT(-0400)] <athena7> which can result in problems
[11:40:50 EDT(-0400)] <EricDalquist> but you only include one of these urls on a page
[11:41:01 EDT(-0400)] <EricDalquist> if you need more you use a different URL with more options
[11:41:03 EDT(-0400)] <dstn> EricDalquist we are at a little coffee shop. Stopped in for a coffee before we're out
[11:41:06 EDT(-0400)] <EricDalquist> it may be more downloads for the user
[11:41:16 EDT(-0400)] <athena7> so the problem is you may sometimes want to include something from a portlet
[11:41:25 EDT(-0400)] <athena7> the portal won't always know what all to include
[11:41:26 EDT(-0400)] <EricDalquist> yup
[11:41:36 EDT(-0400)] <EricDalquist> and that problem isn't going to get fixed by this approach
[11:41:37 EDT(-0400)] <athena7> for example, we don't include the calendar stuff by default, because it's kind of a lot of javascript
[11:41:45 EDT(-0400)] <athena7> we need to address that problem, though
[11:41:51 EDT(-0400)] <athena7> that's currently not broken
[11:42:04 EDT(-0400)] <EricDalquist> yeah, I have no idea what a reasonable approach to that is