[09:49:59 CST(-0600)] <rickard> How do you override user editable "portlet.xml Preferences"? There's no "Edit configuration" link or anything like that in portlet manager.
[09:53:19 CST(-0600)] <holdorph> in portlet manager there should be an option to go to a portlet preferences screen
[09:53:27 CST(-0600)] <holdorph> on that screen click the 'edit preferences' button
[09:53:38 CST(-0600)] <holdorph> then 'add parameter'
[09:54:27 CST(-0600)] <holdorph> fill in the value, then 'review', then 'save'
[09:58:23 CST(-0600)] <rickard> Hmm
[09:59:18 CST(-0600)] <rickard> Can't seem to find the edit preferences button.
[10:00:57 CST(-0600)] <holdorph> http://dl.dropbox.com/u/998658/prefs.png
[10:01:02 CST(-0600)] <holdorph> is what it looks like for me
[10:01:04 CST(-0600)] <rickard> http://www.ch.lu.se/portlet-manager.png
[10:01:37 CST(-0600)] <EricDalquist> ah so if the portlet has config mode, which that one does, you can't edit the preferences directly
[10:01:38 CST(-0600)] <rickard> Is it because this portlet supports "rich configuration"?
[10:01:45 CST(-0600)] <holdorph> yup
[10:01:47 CST(-0600)] <rickard> Ok
[10:01:58 CST(-0600)] <holdorph> yeah, i'm not a big fan of that, but it is what it is
[10:01:59 CST(-0600)] <rickard> So then I have to modify the portlet.xml and redeploy?
[10:02:12 CST(-0600)] <EricDalquist> that is on purpose to prevent breaking the portlet config generated by the config mode
[10:02:24 CST(-0600)] <holdorph> yeah, but you're in the admin screens
[10:02:36 CST(-0600)] <holdorph> it's not like you can't break the portlet a ton of other ways
[10:02:45 CST(-0600)] <EricDalquist> true
[10:02:55 CST(-0600)] <EricDalquist> perhaps add it back in with a big warning?
[10:03:03 CST(-0600)] <holdorph> it just makes my job harder if i know what I really want to do
[10:03:18 CST(-0600)] <holdorph> it's ESPECIALLY annoying when config mode decides to break for a point release or two
[10:03:28 CST(-0600)] <rickard> 
[10:03:59 CST(-0600)] <holdorph> big warning would be fine. i'm sure admins are used to seeing those.
[10:09:01 CST(-0600)] <rickard> athena: Hate to bug you even more about this, but just so we're clear. Even though adding the charset stuff to rdbm.properties solved my main utf8 issues with the portlet, it still doesn't work with cleanContent=true. Just type a non-ascii character in the editor and hit preview to see what I mean.
[10:09:15 CST(-0600)] <athena> ok
[10:09:25 CST(-0600)] <athena> i suspect that may be an issue with tomcat's default encoding
[10:09:31 CST(-0600)] <athena> and yes, i've seen what you'er talkign about
[10:09:54 CST(-0600)] <rickard> Hmm, ok.
[10:10:55 CST(-0600)] <rickard> Do you mean the URIEncoding stuff we talked about the other day?
[10:14:43 CST(-0600)] <rickard> I'll look into it.
[10:16:20 CST(-0600)] <rickard> Another quick question. What's the best way to completely uninstall and remove a portlet? I can remove the folder from the webapps folder in Tomcat and delete the portlet using portlet manager, men what about from the uPortal source? If I redeploy uPortal it'll put them back in, right?
[10:17:19 CST(-0600)] <holdorph> if it's one of the ones shipped with uportal, yup. you'd have to edit the (looks up the file name)
[10:18:15 CST(-0600)] <holdorph> uportal-portlets-overlay/pom.xml and remove the entry from the modules list
[10:18:28 CST(-0600)] <holdorph> i think that's the simplest way, although I haven't tested that theory 
[10:18:36 CST(-0600)] <rickard>
[10:18:41 CST(-0600)] <rickard> I'll give it a go.
[10:18:43 CST(-0600)] <rickard> Thanks.
[10:19:10 CST(-0600)] <holdorph> that's only in addition to the two things you mentioned (removing the web app and deleting from portlet manager)
[10:19:29 CST(-0600)] <rickard> Ok
[10:21:14 CST(-0600)] <rickard> athena: Adding URIEncoding="UTF-8" to the Connector in server.xml did indeed solve the antisamy stuff. Weird that the URI encoding would affect this. I mean, is the portlet passing the data to AntiSamy via GET?
[10:23:06 CST(-0600)] <athena> yep
[10:23:13 CST(-0600)] <athena> and via post
[10:23:18 CST(-0600)] <athena> which i'm a bit more concerned about
[10:23:29 CST(-0600)] <athena> the content gets checked twice
[10:23:37 CST(-0600)] <athena> first when you exist "preview" mode before you save
[10:23:51 CST(-0600)] <rickard> Ah, ok.
[10:23:55 CST(-0600)] <athena> that ajax operation is designed to give you an accurate preview of your content - so you know right away if antisamy is going to delete some key element
[10:24:05 CST(-0600)] <rickard> Makes sense.
[10:24:07 CST(-0600)] <athena> then of course the whole form gets posted so the back-end code can save it
[10:24:31 CST(-0600)] <athena> and we re-parse it there to make sure it hasn't changed, though i'm not actually that worried about a privileged administrator hacking the page to get around the preview
[10:24:37 CST(-0600)] <athena> good practice to double check though
[10:26:06 CST(-0600)] <rickard> Yeah, but if it turns out to be a problem for i18n, it might be worth skipping.
[10:26:10 CST(-0600)] <rickard> In my opinion.
[10:26:37 CST(-0600)] <rickard> If a malicious user has admin access, we're screwed anyway.
[10:29:42 CST(-0600)] <rickard> I take that back. Adding URIEncoding="UTF-8" did not solve it. It makes it work with characters from latin1 (e.g å, ä, ö etc), but not multibyte characters.
[10:29:48 CST(-0600)] <rickard> Man, this is confusing.
[10:32:28 CST(-0600)] <rickard> Oh well, time to head home. Have a good weekend.
[10:33:02 CST(-0600)] <athena> i suspect that what we really need is UTF-8 support for POST parameters
[10:33:49 CST(-0600)] <rickard> I believe we have that.
[10:34:17 CST(-0600)] <rickard> As long as the browser considers the page on which the form resides to be UTF8, it should post the data as UTF8.
[10:34:44 CST(-0600)] <rickard> That is unless tomcat does something strange behind the scenes.
[10:37:29 CST(-0600)] <rickard> Bye
[10:37:35 CST(-0600)] <athena> actually a tomcat problem
[10:37:41 CST(-0600)] <athena> but we can talk next week - have a great weekend!
[10:37:45 CST(-0600)] <athena> thanks again for all your help on this
[13:21:14 CST(-0600)] <EricDalquist> drooling a little over the spring security 3.0 annotations: http://static.springsource.org/spring-security/site/docs/3.0.x/reference/el-access.html#el-pre-post-annotations
[13:47:26 CST(-0600)] <athena> yeah, combined with EL that stuff gets super cool
[13:47:44 CST(-0600)] <athena> would love to move to spring security
[14:57:12 CST(-0600)] <awills> Happy Friday
[14:57:22 CST(-0600)] * athena cheers heartily
[14:57:37 CST(-0600)] <awills> just posetd this (note also sent to list): https://issues.jasig.org/browse/UP-2927
[14:58:16 CST(-0600)] * holdorph wonders if awills knows about the new #jasig-uportal channel
[14:58:18 CST(-0600)] <awills> I think this is a wanted feature... seeking input to best align this work with the preferences and plans of others in the community
[14:58:34 CST(-0600)] <EricDalquist> using either channel is fine right now 
[14:58:44 CST(-0600)] <EricDalquist> they both get logged to the same location
[14:58:49 CST(-0600)] <awills> news to me... amking a note
[14:59:09 CST(-0600)] <EricDalquist> I'll setup the forward to move people into #jasig-uportal this weekend
[14:59:11 CST(-0600)] <athena> yes, i think that's totally a wanted feature
[14:59:22 CST(-0600)] <EricDalquist> yes I agree
[14:59:30 CST(-0600)] <athena> should add that channel to my auto-joins
[14:59:33 CST(-0600)] <awills> step thrrough the patch, if you have a few minutes
[14:59:45 CST(-0600)] <EricDalquist> will do
[14:59:52 CST(-0600)] <awills> awesomeness
[15:00:18 CST(-0600)] <athena> woo features!
[15:00:23 CST(-0600)] <athena> think that really makes sense
[15:00:32 CST(-0600)] <athena> and hopefully shouldn't be a big lift
[15:02:06 CST(-0600)] <EricDalquist> looks good
[15:02:57 CST(-0600)] <awills> very cool... i'll have to do a bit of rework for the 3.3. version... but that's fine
[15:03:15 CST(-0600)] <EricDalquist> it would be neat to just integrate it into the gallery ui in trunk
[15:03:38 CST(-0600)] <EricDalquist> maybe talk with matt/gary and see if they have ideas on where a good place to put a reset link would be
[15:03:53 CST(-0600)] <awills> do you mean a link to it? or the feature itself?
[15:04:20 CST(-0600)] <EricDalquist> well a link to do the actual reset
[15:04:28 CST(-0600)] <EricDalquist> the backend impl could be wired into a REST api
[15:04:48 CST(-0600)] <athena> that's not a bad idea
[15:05:06 CST(-0600)] <athena> we'd probably want to make sure there's a big confirmation
[15:05:10 CST(-0600)] <EricDalquist> right
[15:05:11 CST(-0600)] <athena> but that might be convenient
[15:05:19 CST(-0600)] <EricDalquist> and the logical place for a user
[15:05:24 CST(-0600)] <athena> ya
[15:05:35 CST(-0600)] <athena> even a link to the portlet wouldn't be a bad place to start
[15:05:37 CST(-0600)] <EricDalquist> since that is where they do everything else ui related
[15:05:39 CST(-0600)] <EricDalquist> yup
[15:10:05 CST(-0600)] <awills> yeah the portlet at least has real estate to show a properly ominous warning
[15:10:11 CST(-0600)] <EricDalquist> just spend 2 days fixing threaded portlet entity persistence 
[15:10:14 CST(-0600)] <EricDalquist> spent*
[15:10:16 CST(-0600)] <awills> esp. in focus mode
[16:34:17 CST(-0600)] <awills> for anyone who's still here... i'm having difficulty with the latest rel-2-3-patches...
[16:34:21 CST(-0600)] <awills> links like http://localhost:8080/uPortal/render.userLayoutRootNode.uP?uP_root=root&amp;uP_sparam=activeTab&amp;activeTab=3
[16:34:45 CST(-0600)] <awills> i hope this isn't a matter of changed data w/ the HTML serializer
[16:34:51 CST(-0600)] <athena> it is
[16:34:53 CST(-0600)] <holdorph> 2-3 patches or 3-2 patches?
[16:34:59 CST(-0600)] <athena> 3-2-patches
[16:35:05 CST(-0600)] <awills> 3-2-patches
[16:35:14 CST(-0600)] <awills> lol @2-3 patches
[16:35:17 CST(-0600)] <athena> so it looks like the changes we made to get content to validate under HTML are problematic under XHTML
[16:35:34 CST(-0600)] <athena> of course, as eric's pointed out we're not actually doing XHTML, so our doctype declaration is a big fat lie
[16:35:53 CST(-0600)] <athena> so the easy fix is to go update your theme registrations to use the HTML serializer
[16:36:19 CST(-0600)] <awills> that's what i was afraid of
[16:36:22 CST(-0600)] <athena> but i'm a bit worried about requiring that as a step for a minor dot release
[16:36:43 CST(-0600)] <athena> and unfortunately it's also not going to be trivial to toggle that between serializers, though we may be able to do it
[16:36:52 CST(-0600)] <athena> i would recommend that we strongly encourage people to switch serializers though
[16:37:01 CST(-0600)] <athena> doesn't seem to hurt anything, and you actually get valid markup
[16:37:08 CST(-0600)] <awills> still it might me the best among 2 difficult choices... what were the motivations for moving to the HTML serializer
[16:37:09 CST(-0600)] <awills> ?
[16:37:38 CST(-0600)] <awills> guess i should read as well as type 
[16:40:35 CST(-0600)] <athena> we've discussed it a bit in chat over the last few days, but essentially the motivation is that we can't really enforce XHTML in the portal environment
[16:40:54 CST(-0600)] <athena> from what eric said, it's not really valid XHTML unless the content-type is set to xml
[16:41:05 CST(-0600)] <athena> at which point browsers will crash horribly if there are any validation errors
[16:41:18 CST(-0600)] <athena> which means a single error in a portlet would cause some big problems
[16:41:37 CST(-0600)] <athena> and then with jsr-286 we can't actually do xhtml unless all portlets support it
[16:41:56 CST(-0600)] <athena> that's my quick summary, anyway - would be best to ask him for more details
[16:42:27 CST(-0600)] <athena> anyway, valid markup has started to be a concern for some of our clients (accessibility guidelines, etc.), and of course it'd be nice to say that our theme validates
General
Content
Integrations