Page Comparison

[12:19:52 CDT(-0500)] <athena> EricDalquist: we shouldn't have portlet parameters that start with PORTLET. anymore, right?
[12:20:00 CDT(-0500)] <EricDalquist> right
[12:20:17 CDT(-0500)] <EricDalquist> there is are separate preference elements for portlet preferences now
[12:21:10 CDT(-0500)] <athena> yeah
[12:21:18 CDT(-0500)] <athena> that's a hold over from when there wasn't, right?
[12:21:32 CDT(-0500)] <EricDalquist> yup
[12:21:35 CDT(-0500)] <athena> going through and adding support for readOnly preferences back into the portlet admin portlet
[12:21:43 CDT(-0500)] <athena> and need to fix the parameters and review pages
[12:21:45 CDT(-0500)] <EricDalquist> ah got it
[12:21:51 CDT(-0500)] <athena> drives me crazy how messy this code is :/
[12:22:01 CDT(-0500)] <athena> really hard to write unit tests w/ all the groups and permission stuff
[12:23:52 CDT(-0500)] <EricDalquist> yeah it is
[12:27:56 CDT(-0500)] <athena> will be nice to eventually get that fixed
[12:51:41 CDT(-0500)] <athena> do we still have a use case for arbitrary portlet parameters? i'm kind of thinking no
[12:53:09 CDT(-0500)] <EricDalquist> like just letting the user enter random stuff for the portlet layout parameters?
[12:57:14 CDT(-0500)] <athena> yeah
[12:57:34 CDT(-0500)] <athena> i think we used to have that because individual IChannels might need some custom parameter
[12:57:45 CDT(-0500)] <athena> and if you were using the "custom" channel type it wouldn't knwo to prompt
[12:57:55 CDT(-0500)] <athena> but i don't know that we need it anymoreO?
[12:58:20 CDT(-0500)] <EricDalquist> right
[12:58:30 CDT(-0500)] <EricDalquist> and I don't think we would
[12:58:41 CDT(-0500)] <EricDalquist> since they are now only used by the XSL
[12:58:41 CDT(-0500)] <athena> ok
[12:58:43 CDT(-0500)] <athena> yeah
[12:58:53 CDT(-0500)] <athena> and you can pretty easily add a new param into the CPD
[12:59:10 CDT(-0500)] <athena> want me to pull that stuff out?
[12:59:28 CDT(-0500)] <EricDalquist> sure
[12:59:45 CDT(-0500)] <EricDalquist> and we have like a 'shared cpd' that most of the other CPDs build off of right?
[12:59:50 CDT(-0500)] <EricDalquist> so you can even just add it in one spot?
[13:02:04 CDT(-0500)] <athena> yep
[13:12:58 CDT(-0500)] <athena> so where are we with determining what modes portlets have? looks like that might be in a bit of an in-between state
[13:13:10 CDT(-0500)] <athena> are we no longer tracking that as part of the portlet model?
[13:13:46 CDT(-0500)] <EricDalquist> like what modes it supports?
[13:14:18 CDT(-0500)] <athena> yeah
[13:14:38 CDT(-0500)] <EricDalquist> that should all be provided by the pluto object model
[13:14:57 CDT(-0500)] <EricDalquist> which you can get from the portlet definition registry with the portlet webapp name & portlet name
[13:16:00 CDT(-0500)] <athena> so what if there's a portlet that supports edit mode, but the deployer doesn't want it to be user-editable?
[13:18:17 CDT(-0500)] <athena> it kind of looks like there are also portlet definition parameters modeling which portlets have edit/help/about mode?
[13:18:31 CDT(-0500)] <EricDalquist> yeah
[13:18:45 CDT(-0500)] <EricDalquist> so there used to be has edit/help/about directly on the portlet definition object
[13:19:02 CDT(-0500)] <EricDalquist> when I did the import/export update I moved them to parameters
[13:19:16 CDT(-0500)] <athena> ok, cool - just wanted to make sure that was the plan
[13:19:26 CDT(-0500)] <EricDalquist> I don't think there has ever been a tie from what a portlet actually declares support for to the function of those parameters
[13:19:28 CDT(-0500)] <athena> looks like maybe that stuff isn't coming through into the theme quite right yet
[13:19:32 CDT(-0500)] <EricDalquist> that would be a nice tie to have
[13:19:44 CDT(-0500)] <EricDalquist> huh, I wonder if I forgot to commit that
[13:19:54 CDT(-0500)] <athena> actually i think we use the actual portlet mode support as a default
[13:20:11 CDT(-0500)] <athena> so in theory if the portlet supports edit mode, the UX should default to turnning edit mode on, but you can override that
[13:21:04 CDT(-0500)] <EricDalquist> got it
[13:35:45 CDT(-0500)] <athena> what do you think about changing our CPDs to use message codes rather than display strings?
[13:35:53 CDT(-0500)] <athena> maybe that'd be the best way to add support for i18n?
[13:35:53 CDT(-0500)] <EricDalquist> +1
[13:36:02 CDT(-0500)] <athena> ok, i was thinking that would be not-crazy
[13:36:05 CDT(-0500)] <EricDalquist> that is really what we need to do more of
[13:36:07 CDT(-0500)] <athena> yeah
[13:36:15 CDT(-0500)] <athena> really trying to push things to having better support
[13:36:16 CDT(-0500)] <EricDalquist> instead of having all sorts of getDescription(Locale) APIs
[13:36:20 CDT(-0500)] <athena> seems like that'd make a big difference
[13:36:22 CDT(-0500)] <athena> yeah :/
[13:36:36 CDT(-0500)] <EricDalquist> have things return messages codes
[13:36:42 CDT(-0500)] <EricDalquist> and if code lookup fails display the message code string
[13:37:03 CDT(-0500)] <athena> ok, that sounds awesome to me
[13:37:09 CDT(-0500)] <EricDalquist> then we can keep locale support completely in the view layer
[13:37:28 CDT(-0500)] <athena> yeah
[13:37:45 CDT(-0500)] <EricDalquist> and if our codes are decently named they'll still make sense in places where they don't resolve
[13:38:41 CDT(-0500)] <athena> yeah
[13:38:54 CDT(-0500)] <EricDalquist> I was thinking about that stuff when working on the new import/export APIs
[13:39:09 CDT(-0500)] <EricDalquist> since that stuff returns stuff like the name of a portal data type
[13:39:17 CDT(-0500)] <EricDalquist> I should change that to return a message code
[13:39:23 CDT(-0500)] <EricDalquist> and add the code to the messages file
[13:39:40 CDT(-0500)] <EricDalquist> then in theory it could even work for CLI tools
[13:39:46 CDT(-0500)] <EricDalquist> by using the OS's locale
[13:39:47 CDT(-0500)] <athena> hm, interesting
[13:39:49 CDT(-0500)] <athena> yeah that'd be neat
[13:40:19 CDT(-0500)] <athena> i should really take some time and finish that auto-translation plugin
[13:40:30 CDT(-0500)] <athena> got the google gadgets portlet working last night
[13:40:40 CDT(-0500)] <athena> so you can actually search for gadgets directly w/in the web page
[13:40:50 CDT(-0500)] <EricDalquist> neat
[13:40:57 CDT(-0500)] <athena> which of course means it's doing evil HTML parsing of the google gadgets home page and might be fragile
[13:41:03 CDT(-0500)] <athena> but guess it's a decent demo
[13:41:12 CDT(-0500)] <athena> just really wish gadgets could have a flexible width
[13:41:18 CDT(-0500)] <athena> would make them a lot more compelling
[13:42:22 CDT(-0500)] <EricDalquist> :/
[13:43:53 CDT(-0500)] <athena> yeah
[13:44:00 CDT(-0500)] <athena> that's why i've always thought they were really lame
[13:44:08 CDT(-0500)] <athena> you have to explicitly set the gadget width in pixels
[13:44:17 CDT(-0500)] <athena> so it's less awesome than it'd otherwise be in a portal environment
[13:44:19 CDT(-0500)] <EricDalquist> is that because of the iframe use?
[13:44:26 CDT(-0500)] <athena> i guess so
[13:44:34 CDT(-0500)] <EricDalquist> and no way to manipulate it via js?
[13:44:45 CDT(-0500)] <athena> though you can set an iframe to a percentage width, so i don't realy get it
[13:44:54 CDT(-0500)] <athena> maybe it's so the gadgets know how big they are - that's my guess
[13:45:12 CDT(-0500)] <athena> well, we could sort of manipulate it with JS, but i haven't foudn a good way to trigger the width-setting event
[13:45:18 CDT(-0500)] <EricDalquist> I wonder how igoogle does it
[13:45:22 CDT(-0500)] <EricDalquist> since that page deals with resizing
[13:45:33 CDT(-0500)] <athena> we'd have to somehow listen for the initialization
[13:45:34 CDT(-0500)] <athena> yeah
[13:46:53 CDT(-0500)] <athena> ergh, google is misbehaving for me again
[14:18:40 CDT(-0500)] <athena> hmm, maybe it's time to migrate the channel publishing DTD over to an XSD
[14:20:00 CDT(-0500)] <athena> you know, for the controls (edit, about, etc.), i don't even know what the "override" and "include" attributes mean