Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

[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 (smile)
[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> (smile)
[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 (smile)
[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? (wink)
[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 (tongue)
[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 (tongue)
[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 (tongue)
[11:42:04 EDT(-0400)] <EricDalquist> yeah, I have no idea what a reasonable approach to that is
[11:42:44 EDT(-0400)] <dstn> EricDalquist,wanted to say thanks for hostin the conference, it was nice
[11:43:02 EDT(-0400)] <EricDalquist> thanks
[11:43:05 EDT(-0400)] <athena7> i do think we need some way to include only specific files, not dependencies
[11:43:11 EDT(-0400)] <EricDalquist> I thought you weren't leaving until later in the day dstn
[11:43:14 EDT(-0400)] <athena7> maybe we just need a includeDependencies parameter
[11:43:20 EDT(-0400)] <EricDalquist> yeah
[11:43:32 EDT(-0400)] <athena7> developers are escaping! stop them!!
[11:43:42 EDT(-0400)] <dstn> Roger wants to try to catch an early flight and he drove to the airport
[11:44:23 EDT(-0400)] <dstn> So I have to go with him
[11:44:32 EDT(-0400)] <EricDalquist> ah
[11:44:57 EDT(-0400)] <athena7> by the way, anyone have any objections to cutting a milestone tag on the calendar portlet?
[11:45:28 EDT(-0400)] <EricDalquist> nope
[11:46:05 EDT(-0400)] <athena7> thinking we should cut a tag before integrating uwnick's changes
[11:46:11 EDT(-0400)] <athena7> since it will be a decent-sized change
[11:46:22 EDT(-0400)] <athena7> very nice improvement though, he's been doing some great stuff (smile)
[11:46:39 EDT(-0400)] <athena7> we coudl really use some tags on portlets in general
[11:46:42 EDT(-0400)] <athena7> even if they're not releases
[11:58:55 EDT(-0400)] <apetro> +1 for more milestone tags
[11:59:20 EDT(-0400)] <apetro> milestones are cheap, easy, fun. Set no quality expectation, just a sane way to talk about who's doing what with what version
[12:01:01 EDT(-0400)] * rolfm (n=rolfm@cpe-24-31-170-6.columbus.res.rr.com) has joined ##uportal
[12:01:21 EDT(-0400)] <uwnick> sweet!
[12:05:37 EDT(-0400)] <apetro> athena7 ok, you were right. I think I'm now running afoul of the too many JQeuries per square inch problem
[12:07:30 EDT(-0400)] <holdorph> just decrease your resolution. problem solved.
[12:08:36 EDT(-0400)] <lennard1> decrease?
[12:08:41 EDT(-0400)] <athena7> lol
[12:08:44 EDT(-0400)] <lennard1> why not increase?
[12:08:57 EDT(-0400)] <holdorph> you increase the resolution, you'll have more dots
[12:09:02 EDT(-0400)] <athena7> so yeah, apetro, just include only the files you really need, for now
[12:09:03 EDT(-0400)] <holdorph> more dots = more jqueries
[12:09:08 EDT(-0400)] <holdorph> less dots = less queries
[12:09:15 EDT(-0400)] <lennard1> lol
[12:09:22 EDT(-0400)] <athena7> there's a list of what's actually included in a text file next to the jquery and fluid dependencies
[12:09:57 EDT(-0400)] <lennard1> thought that if we increased the dots there would be fewer jqueries per dots. Did not think the jqueries increased with the dots.
[12:11:34 EDT(-0400)] <holdorph> well the problem lies in petro's use of 'queries per inch' which is not a good term to use
[12:12:00 EDT(-0400)] <holdorph> I assume, he "meant" to say "queries per dots" but didn't realize that.
[12:18:15 EDT(-0400)] <apetro> neat. So, athena7, is there any virtue on my getting onto Trunk rather than 3.1M1 as long as I'm back to messing with getting the dependencies in?
[12:18:22 EDT(-0400)] <Bosmon> It's seems this channel is even more "off the wall" than the one I just left...
[12:18:22 EDT(-0400)] <athena7> oh, crap
[12:18:27 EDT(-0400)] <athena7> i'm sorry, i thought you were at trunk
[12:18:30 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[12:18:30 EDT(-0400)] <athena7> yes, use trunk
[12:18:31 EDT(-0400)] <athena7> very much so
[12:18:45 EDT(-0400)] <athena7> i'm not sure what 3.1 m1 has in it
[12:18:47 EDT(-0400)] <athena7> use trunk
[12:18:55 EDT(-0400)] <athena7> look at the file that has all the dependencies listed
[12:19:04 EDT(-0400)] <athena7> for now, include what's missing in your portlet
[12:19:26 EDT(-0400)] <holdorph> Bosman, i try. most of the time this channel is much more serious. got to lighten it up every once in a while.
[12:19:41 EDT(-0400)] <holdorph> of course if you want real fun, you need dan mccallum around to set your IRC topic.
[12:20:32 EDT(-0400)] <athena7> indeed
[12:21:41 EDT(-0400)] * apetro enters Dan's IRC channel just to read the topic line
[12:23:23 EDT(-0400)] <holdorph> it's kind of sub par at the moment, but not always that way
[12:26:55 EDT(-0400)] <apetro> ok. How useful would it be for me to do a blog post about getting the AjaxNotepadPortlet to be included in the build, have the right dependencies, etc? I'm weighing the tradeoff of documenting issues encountered vs. the time it takes to write these things.