uPortal IRC Logs-2010-12-17

[09:28:14 CST(-0600)] <rickard> ajan: Regarding your issue with UTF-8 and the SimpleContentPortlet. CKEditor, the WYSIWYG-editor used by the portlet, has some configuration options you might try.
[09:28:50 CST(-0600)] <rickard> ajan: Setting config.entities might help.
[09:28:57 CST(-0600)] <rickard> Setting it to false that is.
[10:00:28 CST(-0600)] <athena> EricDalquist: i'm playing w/ the channel -> portlet stuff a bit and have a couple questions when you have time
[10:00:35 CST(-0600)] <EricDalquist> sure
[10:08:03 CST(-0600)] <athena> so first - i think probably the portlet definition needs a visible id?
[10:08:13 CST(-0600)] <athena> right now the visible id is the not-a-number java object one
[10:08:44 CST(-0600)] <EricDalquist> right, that was originally by design for all the new hibernate managed objects to make ids in method arguments more obvious
[10:09:11 CST(-0600)] <EricDalquist> what problems is the IPortletDefintionId versus long causing?
[10:09:33 CST(-0600)] <athena> well, we need to be able to look up channels by an identifier
[10:09:48 CST(-0600)] <athena> or look up permissions by an identifier
[10:10:52 CST(-0600)] <athena> hm - i guess that does still return an id, just a string one?
[10:10:54 CST(-0600)] <athena> i guess that works
[10:10:56 CST(-0600)] <EricDalquist> yeah
[10:11:19 CST(-0600)] <EricDalquist> so the goal (and I'm more than open to talking about the usefulness of it) is that you would do something like:
[10:12:04 CST(-0600)] <EricDalquist> String portletDefIdStr = request.getParameter("portletId");
[10:12:04 CST(-0600)] <EricDalquist> IPortletDefinitionId portletDefId = portletRegistry.getPortletDefinitionId(portletDefIdStr);
[10:12:13 CST(-0600)] <EricDalquist> I'm not really sure if it is worth the extra step
[10:12:33 CST(-0600)] <EricDalquist> but the original idea was that you'd have one API that converted a String to the Id object
[10:12:39 CST(-0600)] <EricDalquist> and every other API uses the ID object
[10:13:25 CST(-0600)] <EricDalquist> to make the API more self-documenting about what the method arguments are
[10:13:37 CST(-0600)] <EricDalquist> so yeah ... I still wonder if it is worht that extra step
[10:14:10 CST(-0600)] <athena> hmm.
[10:14:44 CST(-0600)] <athena> most of the places we're using portlet ids don't really have anything to do with the request
[10:15:09 CST(-0600)] <EricDalquist> yeah, and so if you're working off of an existing portlet object you should already have access to the object ID
[10:15:14 CST(-0600)] <EricDalquist> so there isn't an extra step
[10:15:18 CST(-0600)] <athena> yeah, i see what you mean
[10:15:36 CST(-0600)] <athena> i just need to look through the API
[10:15:52 CST(-0600)] <athena> think that makes sense
[10:15:52 CST(-0600)] <athena> ok
[10:16:06 CST(-0600)] <athena> another question - do we want to continue to have a separate PortletRegistryStore?
[10:16:38 CST(-0600)] <EricDalquist> probably not ... perhaps anything method that really needs to be saved can be folded into the IPortletDefinitionRegistry?
[10:18:16 CST(-0600)] <EricDalquist> also are we still maintaining that channel registry XML document in trunk?
[10:18:18 CST(-0600)] <EricDalquist> I can't remember
[10:18:22 CST(-0600)] <EricDalquist> if so that needs to go away
[10:18:35 CST(-0600)] <athena> i'm not sure, but if so, it does
[10:19:12 CST(-0600)] <athena> so the portlet definition registry has a bunch of convenience methods for doing things like publishing portlets, etc. that wrap up a bit more than persistence functionality
[10:19:21 CST(-0600)] <athena> but maybe those can be folded into the channel publishing service?
[10:19:57 CST(-0600)] <EricDalquist> yeah
[10:20:16 CST(-0600)] <athena> ok
[10:20:29 CST(-0600)] <athena> that interface also wraps up a ton of "portlet category" methods
[10:20:37 CST(-0600)] <athena> getting the root one, enumerating the portlets in a category, etc.
[10:20:50 CST(-0600)] <athena> those are actually all wrappers for the groups API (portlet categories are just groups)
[10:21:04 CST(-0600)] <athena> i don't know if we want to have some kind of PortletCategoryService or what
[10:21:15 CST(-0600)] <athena> it also allows you to create new categories, etc., by wrapping the groups api
[10:21:28 CST(-0600)] <rickard> athena: I've been looking at adding locale support to SimpleContentPortlet based on what we discussed yesterday. Currently, I'm working on the configuration stuff and I'm not sure how to do the UI stuff. I'm trying to add a drop-down list with the available locales, but this is my first encounter with spring-mvc (or jsp for that matter), so I'm a bit lost.
[10:21:30 CST(-0600)] <athena> not sure if we should really be wrapping all that,b ut then again, the groups api isn't the easiest thing to work with
[10:21:42 CST(-0600)] <athena> rickard: that's a good question
[10:21:47 CST(-0600)] <athena> drop-down seems reasonable
[10:22:02 CST(-0600)] <athena> if you want to populate it from java there's a way to do that and then bind to that as a select list
[10:22:03 CST(-0600)] <EricDalquist> hrm, yeah we do need to preserve that logic
[10:22:15 CST(-0600)] <athena> let me get you a reference
[10:22:26 CST(-0600)] <athena> EricDalquist: ok, cool. maybe a PortletCategoryService then?
[10:22:39 CST(-0600)] <EricDalquist> breaking it up into more coherent pieces sounds like a good approach. move some into the portlet publishing servlet, other into the category and others into the portlet definition registry
[10:23:36 CST(-0600)] <rickard> athena: Yeah, that's the idea. I imagine that ContentForm.java is the model, ConfigureContentController.java is the controller and configureContent.jsp is the view. I'm not sure where the list of locales should live though.
[10:24:33 CST(-0600)] <athena> hang on - i know what you need
[10:24:38 CST(-0600)] <rickard>
[10:25:51 CST(-0600)] <athena> http://static.springsource.org/spring/docs/2.5.6/reference/mvc.html#mvc-ann-modelattrib
[10:26:01 CST(-0600)] <athena> take a look at the populatePetTypes() method
[10:26:28 CST(-0600)] <athena> you can basically have a little method that returns all the available locales, and annotate it with the name it should show up as in the view
[10:26:31 CST(-0600)] <athena> you add that to the controller
[10:26:51 CST(-0600)] <rickard> Reading...
[10:26:53 CST(-0600)] <athena> then from the view you can use the spring form:select tag
[10:34:51 CST(-0600)] <rickard> Hmm. How do I get access to the request-object from my version of the populatePetTypes method?
[10:34:57 CST(-0600)] <rickard> I need it to get the list of locales.
[10:37:41 CST(-0600)] <athena> EricDalquist: do we want to continue to have methods like getAllManageableChildChannels?
[10:37:58 CST(-0600)] <EricDalquist> is it used anywhere right now?
[10:38:02 CST(-0600)] <athena> yes
[10:38:53 CST(-0600)] <athena> hm
[10:38:57 CST(-0600)] <athena> maybe not
[10:39:08 CST(-0600)] <athena> might just be the channel list
[10:39:25 CST(-0600)] <EricDalquist> nice
[10:39:38 CST(-0600)] <EricDalquist> if there are method that aren't called I'd just nuke em
[10:40:04 CST(-0600)] <EricDalquist> stuff that is used, don't worry about trying to refactor too much external the the core portlet/channel definition related APIs
[10:40:17 CST(-0600)] <EricDalquist> we can worry about that after this initial re-org and consolidation
[10:40:26 CST(-0600)] <athena> maeks sense
[10:46:35 CST(-0600)] <athena> how's the search stuff going?
[10:48:11 CST(-0600)] <rickard> Question. Does request.getLocales() return the locales defined in portal.properties or the browser locales?
[10:49:09 CST(-0600)] <athena> my guess is it's per-user?
[10:50:12 CST(-0600)] <EricDalquist> it is the locale's the user has picked via the locale selector in uPortal
[10:50:38 CST(-0600)] <rickard> Isn't that what getLocale() returns?
[10:50:48 CST(-0600)] <EricDalquist> locales returns the full list
[10:50:49 CST(-0600)] <rickard> getLocale() and getLocales()
[10:50:56 CST(-0600)] <EricDalquist> since in theory the user can order them
[10:51:05 CST(-0600)] <EricDalquist> not sure the locale selector ui allows that
[10:51:12 CST(-0600)] <EricDalquist> but the underlying code model does
[10:51:14 CST(-0600)] <rickard> So it's the list from the browSER?
[10:51:17 CST(-0600)] <rickard> ser
[10:51:34 CST(-0600)] <athena> there's a mechanism in uportal that lets the user set their locale
[10:51:39 CST(-0600)] <athena> so it might or might not be the same as the browser
[10:51:41 CST(-0600)] <EricDalquist> no, it is the list of locales that uPortal knows about for the user
[10:51:47 CST(-0600)] <athena> the UI selector does not allow ordering
[10:52:24 CST(-0600)] <rickard> But what I need is the list of locales that are enabled in uPortal (the list from portal.properties).
[10:52:42 CST(-0600)] <rickard> I
[10:52:53 CST(-0600)] <athena> i don't think there's a way to get that from uportal, since the portlet is in a different context
[10:53:07 CST(-0600)] <rickard> But the user locales selector picks it up.
[10:53:18 CST(-0600)] <athena> yeah - that's actually part of the uportal webapp
[10:53:22 CST(-0600)] <rickard> Aha
[10:53:24 CST(-0600)] <athena> so it has acccess to that API
[10:53:26 CST(-0600)] <rickard> Bummer.
[10:53:28 CST(-0600)] <athena> if it were me i'd probably separately spring-configure it in the portlet
[10:53:49 CST(-0600)] <athena> and then once we figure out this whole filtering strategy, that could be a filter-token property that gets applied in both uportal and the webapp
[10:53:52 CST(-0600)] <rickard> Or add it as a new portal preference, maybe.
[10:54:36 CST(-0600)] <rickard> portlet preference that is
[10:55:46 CST(-0600)] <rickard> Oh well, time to go home for the weekend. Hopefully, I'll have more time to work on this next week.
[10:56:51 CST(-0600)] <athena> yeah - adding it as a portlet preference would be completely reasonable
[10:56:53 CST(-0600)] <athena> have a great weekend
[10:57:05 CST(-0600)] <rickard> You too. Later.
[10:58:47 CST(-0600)] <EricDalquist> athena: what resolution do you usually record screen-casts in?
[10:58:57 CST(-0600)] <EricDalquist> is 1024x768 the max I should do?
[10:59:33 CST(-0600)] <athena> hmmm
[10:59:39 CST(-0600)] <athena> i always forget what youtube HD is
[10:59:43 CST(-0600)] <athena> usually i do that
[11:00:25 CST(-0600)] <athena> 1280 x 720?
[11:00:41 CST(-0600)] <EricDalquist> ah yeah ok
[11:01:09 CST(-0600)] <EricDalquist> unfortunatly the screen recording tool I found for ubuntu doesn't let me specify a record area size. it is easier to just do the whole monitor
[11:01:18 CST(-0600)] <EricDalquist> so I think I'll stick with 1024x768 for now :/
[11:01:37 CST(-0600)] <athena> sad
[11:01:41 CST(-0600)] <EricDalquist> yeah
[11:01:46 CST(-0600)] <EricDalquist> I can just draw a box
[11:01:53 CST(-0600)] <EricDalquist> but it doesn't tell me how big it is :/
[11:01:55 CST(-0600)] <athena> so if you want, i do have some tools that can cut down the screen later
[11:02:11 CST(-0600)] <athena> i usually have to record my whole screen, but then i pare it down to the part i actually want
[11:02:13 CST(-0600)] <EricDalquist> ok
[11:02:22 CST(-0600)] <athena> i think you can do it with iMovie too, if you have access to that
[11:02:28 CST(-0600)] <EricDalquist> yeah I do
[11:02:35 CST(-0600)] <EricDalquist> I figure I'll do the editing on my mac
[11:02:44 CST(-0600)] <athena> should be just fine then
[11:02:45 CST(-0600)] <EricDalquist> just easier to do the initial recording on my work machine
[11:02:50 CST(-0600)] <athena> yeah, that makes sense
[11:03:04 CST(-0600)] <athena> so yeah, in that case you can just record the whole screen, then kind of clip out the part you want
[11:03:13 CST(-0600)] <athena> that's what i normally do w/ the community call demos
[11:03:20 CST(-0600)] <athena> since typically we get the whole window recorded
[11:04:31 CST(-0600)] <EricDalquist> sounds good
[11:10:17 CST(-0600)] <athena> does this method exist right now? portletRegistry.getPortletDefinitionId(portletDefIdStr);
[11:10:54 CST(-0600)] <EricDalquist> hrm I think so
[11:11:12 CST(-0600)] <EricDalquist> actually it may not
[11:11:19 CST(-0600)] <athena> or i guess i can just use getPortletEntity(String)?
[11:11:22 CST(-0600)] <EricDalquist> because of the relationship that portlet/channel defs had
[11:12:19 CST(-0600)] <EricDalquist> you may have to clone public IPortletEntity getPortletEntity(String portletEntityIdString); from IPortletEntityRegistry and convert it to work for definitions
[11:12:19 CST(-0600)] <athena> er, that's a portlet entity i guess, not a portlet definition
[11:12:44 CST(-0600)] <athena> we do need to get portlets by fname too
[11:12:52 CST(-0600)] <athena> guess maybe we need a getPortletEntityByFname
[11:13:11 CST(-0600)] <athena> maybe that and getPortletEntityById? don't want that overlap to be confusing
[11:13:26 CST(-0600)] <EricDalquist> getPortletDefinitionByFname
[11:13:59 CST(-0600)] <EricDalquist> so I don't think any of the PortletEntity methods will be touched by this work
[11:14:00 CST(-0600)] <athena> er, yes, that
[11:14:09 CST(-0600)] <athena> yes, hoepfully not
[11:14:14 CST(-0600)] <athena> i assume that's the user-specific part?
[11:16:03 CST(-0600)] <EricDalquist> yeah so:
[11:16:03 CST(-0600)] <EricDalquist> definition = publishing instance via portlet manager
[11:16:03 CST(-0600)] <EricDalquist> entity = subscribed to instance in a user's layout
[11:16:03 CST(-0600)] <EricDalquist> window = view into an entity, you can have multiple views if you do something like use DETACHED WindowState to pop up a portlet
[11:17:38 CST(-0600)] <athena> ah, makes sense
[11:17:39 CST(-0600)] <athena> cool
[11:17:58 CST(-0600)] <EricDalquist> so it is this big tree structure
[11:18:35 CST(-0600)] <EricDalquist> and at the base are descriptors (unfortunatly pluto changed the name of these from 1.1 to 2.0 and pluto now calls them definitions too) which are the java object model of the portlet.xml
[11:21:15 CST(-0600)] <athena> ergh - this id implementation isn't currently visible to the registry
[11:21:47 CST(-0600)] <EricDalquist> how does the entity registry/dao handle it?
[11:22:07 CST(-0600)] <athena> looking into it
[11:23:18 CST(-0600)] <EricDalquist> I'm assuming it is easy to clip out dead spots in the screencast video too right?
[11:23:29 CST(-0600)] <EricDalquist> I keep forgetting about it and there are like 5 minute pauses of nothing happening
[11:26:47 CST(-0600)] <athena> yes, that should be easy too
[11:27:03 CST(-0600)] <athena> i personally find imovie a little hard to work with sometimes
[11:27:05 CST(-0600)] <athena> but all that's possible
[11:27:10 CST(-0600)] <athena> easier w/ camtasia
[11:28:49 CST(-0600)] <awills> good morning EricDalquist... i ran into an issue with StructureStylesheetUserPreferences today... contemplating refactoring & updating that code
[11:29:09 CST(-0600)] <EricDalquist> what version?
[11:29:21 CST(-0600)] <awills> 3.2
[11:29:31 CST(-0600)] <awills> 3.2.(almost)5
[11:29:38 CST(-0600)] <EricDalquist> well that code is going to be VERY different in trunk
[11:29:59 CST(-0600)] <EricDalquist> but refactoring in 3.2 is ok if the end result is 100% API & functionally compatible
[11:30:24 CST(-0600)] <awills> if you re-import a frag layout and the arrangement of folders has changed, strange things can happen... even for users with no customizations to the fragment
[11:30:24 CST(-0600)] <EricDalquist> so adding features is fine but we can't really change the behavior or remove/change APIs in a patch
[11:30:41 CST(-0600)] <awills> ah no... was thinking only of refactoring in trunk
[11:30:50 CST(-0600)] <awills> but looks like it's already been handled
[11:30:55 CST(-0600)] <EricDalquist> well it is in-progress there
[11:31:02 CST(-0600)] <EricDalquist> this may still be an issue
[11:31:12 CST(-0600)] <EricDalquist> the changes I'm working on are related to the new URL and rendering pipeline
[11:31:22 CST(-0600)] <awills> that's fine too... i just know that code (3.2. version) is very old, and could use some updates
[11:31:22 CST(-0600)] <EricDalquist> so that things like the activeTab parameter aren't stored in the user's session
[11:31:29 CST(-0600)] <EricDalquist> they would be coming from the request every time
[11:31:39 CST(-0600)] <awills> how very RESTful
[11:31:53 CST(-0600)] <EricDalquist> essentially I want to break it up into 3 layers for both theme and struct
[11:32:03 CST(-0600)] <EricDalquist> request sourced data, session sourced data and persisted data
[11:32:14 CST(-0600)] <EricDalquist> and hopefully we can move a lot of it to request sourced
[11:32:26 CST(-0600)] <EricDalquist> so you can actually navigate in multiple browser windows
[11:32:36 CST(-0600)] <EricDalquist> but I'm curious what the problem is with the dlm import?
[11:32:45 CST(-0600)] <EricDalquist> what is StructureStylesheetUserPreferences breaking?
[11:33:21 CST(-0600)] <awills> 1 sec
[11:34:08 CST(-0600)] <EricDalquist> just want to make sure we address it
[11:39:05 CST(-0600)] <awills> i believe it's owing to the structIds changing for the same logical node...
[11:39:23 CST(-0600)] <awills> old version= root / folder1, folder2
[11:39:31 CST(-0600)] <EricDalquist> ah, didn't we fix that in 3.2 by adding structIds to the export?
[11:39:39 CST(-0600)] <awills> new version = root/ folder1, folder3, folder2
[11:40:11 CST(-0600)] <awills> we did... but i discovered this b/c i never replaced my original version with a re-exported one
[11:40:30 CST(-0600)] <awills> we shouldn't need sticky ids for this usage
[11:40:52 CST(-0600)] <awills> the effected users haven't made any customizatons
[11:41:08 CST(-0600)] <EricDalquist> oh .. what do the end users end up seeing?
[11:41:31 CST(-0600)] <awills> looks like default values for struct params
[11:42:00 CST(-0600)] <awills> instead of the ones that were defined & imported
[11:42:12 CST(-0600)] <EricDalquist> huh
[11:42:25 CST(-0600)] <awills> yeah, that was my response
[11:45:13 CST(-0600)] <awills> example: add the highlighted lines and re-import... http://uportal.pastebin.com/m2V0gCG2
[11:46:18 CST(-0600)] <awills> left column becomes 60% (which should be the value for right), right column becomes 100% (which is the default)
[11:46:46 CST(-0600)] <awills> but ONLY for dlm audience members... if you go in as fragment owner it's perfect
[11:47:03 CST(-0600)] <awills> brb
[12:19:36 CST(-0600)] <athena> if we do some refactoring there can we make sure that data is properly associated w/ the profile vs. layout?
[12:19:46 CST(-0600)] <athena> i think we'd talked before about some layout-specific data maybe being in the profile instead
[13:20:25 CST(-0600)] <athena> EricDalquist: do we want to have both a portlet definition registry and a portlet definition dao?
[13:30:50 CST(-0600)] <EricDalquist> YES
[13:30:51 CST(-0600)] <EricDalquist> oops
[13:30:53 CST(-0600)] <EricDalquist> capslock
[13:30:56 CST(-0600)] <EricDalquist> same with entity
[13:31:04 CST(-0600)] <EricDalquist> the idea is that the DAO is just CRUD operations
[13:31:16 CST(-0600)] <EricDalquist> the registry does anything beyond that
[13:31:28 CST(-0600)] <athena> right now the registry has crud operations in it
[13:31:49 CST(-0600)] <EricDalquist> and that the registries would be what client code worked with
[13:31:50 CST(-0600)] <athena> do we want to add wrappers for the CRUD calls to the registry and only really use the registry, or use them separately?
[13:32:18 CST(-0600)] <EricDalquist> I think right now the only things that really talk to the DAOs are the registries
[13:32:32 CST(-0600)] <EricDalquist> again, old design descisions, and I'm always up for revisits
[13:33:01 CST(-0600)] <athena> sure, i can keep adding wrapper methods to the registry if we want
[13:33:09 CST(-0600)] <athena> i don't have a strong opinion
[13:33:21 CST(-0600)] <athena> i don't think we ever created a registry wrapper for the channel dao
[13:33:54 CST(-0600)] <EricDalquist> nope, and I never brought it up since it was only going to live for 1 release
[13:34:38 CST(-0600)] <athena> makes sense
[13:34:53 CST(-0600)] <athena> thanks, just wanted to know what our intention is
[13:34:59 CST(-0600)] <athena> would like to keep things consistent
[13:35:04 CST(-0600)] <EricDalquist> yeah
[13:35:14 CST(-0600)] <EricDalquist> so CRUD wrappers are probably the most consistent with what is there then
[13:35:50 CST(-0600)] <athena> sure, that's fine
[13:36:01 CST(-0600)] <athena> discovered there's actually a class that still does manual SQL calls against the channel table
[13:36:06 CST(-0600)] <athena> never found it before, yuck
[13:36:11 CST(-0600)] <EricDalquist> fun
[13:36:11 CST(-0600)] <athena> RDBMChannelDefSearcher
[13:36:14 CST(-0600)] <athena> yeah
[13:36:16 CST(-0600)] <EricDalquist> I think some of the CRN stuff does too
[13:36:16 CST(-0600)] <athena> gotta fix that
[13:36:28 CST(-0600)] <EricDalquist> renaming things is a good way to find stuff like that
[13:36:33 CST(-0600)] <athena> it may - a lot of it also uses the really old channel publishing service
[13:36:40 CST(-0600)] <athena> i'm a lot more worried about fixing that one
[13:36:47 CST(-0600)] <EricDalquist> yeah
[13:36:55 CST(-0600)] <EricDalquist> that we probably need to talk about a bit more
[13:37:01 CST(-0600)] <athena> yeah
[13:37:03 CST(-0600)] <EricDalquist> how do we want to fix the publishing service
[13:37:08 CST(-0600)] <EricDalquist> actually define some requrements
[13:37:21 CST(-0600)] <athena> yeah i was going to ask you about that
[13:37:40 CST(-0600)] <athena> do we want to think about using JAXB or something like that?
[13:37:57 CST(-0600)] <athena> kind of annoying because of course i can't test any of this code until we have import working
[13:38:09 CST(-0600)] <EricDalquist> yeah
[13:38:23 CST(-0600)] <EricDalquist> well eventually what I would love to use JAXB
[13:38:40 CST(-0600)] <EricDalquist> not quite sure the best way to handle the "upgrade from and old version" though
[13:38:48 CST(-0600)] <EricDalquist> perhaps JAXB + XSLT?
[13:38:57 CST(-0600)] <athena> yeah, that's kind of what i was thinking
[13:39:02 CST(-0600)] <athena> not 100% sure on that though
[13:39:09 CST(-0600)] <EricDalquist> so the import would read just the root XML element via StAX
[13:39:13 CST(-0600)] <EricDalquist> read the version attribute
[13:39:17 CST(-0600)] <EricDalquist> if it is current just bind
[13:39:30 CST(-0600)] <EricDalquist> if not run it through the appropriate XSL(s) to get it up to current then bind
[13:39:45 CST(-0600)] <EricDalquist> JAXB doesn't answer some of the other issue though
[13:40:03 CST(-0600)] <EricDalquist> like when we export we want to convert references that may be done via primary keys in the DB to fname style references
[13:40:03 CST(-0600)] <athena> that seems pretty consistent with the overall strategy we have now - currently we update the XML nodes to match the current version, more or less
[13:40:08 CST(-0600)] <athena> right.
[13:40:27 CST(-0600)] <EricDalquist> and I don't know what the best way to do something like that is
[13:40:27 CST(-0600)] <athena> i don't think we could just use JAXB annotations or anything like that
[13:40:32 CST(-0600)] <athena> might be able to use some of the custom mapper thingies
[13:40:42 CST(-0600)] <EricDalquist> yeah
[13:40:48 CST(-0600)] <EricDalquist> well I have to run again … if the tire shop has wifi I'll be back on in ~ 30 minutes
[13:40:53 CST(-0600)] <EricDalquist> if not I'll be back in ~ 2 hours
[13:40:55 CST(-0600)] <athena> ok, good luck
[14:03:11 CST(-0600)] <EricDalquist> yay for free wifi at the tire shop
[14:09:28 CST(-0600)] <awills_away> So I discovered the root of my problem with SS user prefs earlier...
[14:09:59 CST(-0600)] <awills_away> the RDBMDistributedLayoutStore.updateCachedLayout() method does not update SS user prefs
[14:10:15 CST(-0600)] <awills_away> keeps the older version, already in memory
[14:10:55 CST(-0600)] <awills_away> so... if there are changes to SS user prefs from (1) another server or (2) import/export, they won't be picked up by the fragment cleaner sweeper thing
[14:33:27 CST(-0600)] <athena> welcome back
[14:33:28 CST(-0600)] <EricDalquist> looks like I get to learn the fluid renderer
[14:33:32 CST(-0600)] <athena> oh fun!
[14:33:33 CST(-0600)] <EricDalquist> also … the free wifi is very very spotty
[14:33:35 CST(-0600)] <EricDalquist> yeah
[14:33:38 CST(-0600)] <athena> i actually have come to really like it
[14:33:40 CST(-0600)] <athena> ah, gotcha
[14:33:44 CST(-0600)] <EricDalquist> we have a json based campus search service: http://www.wisc.edu/directories/json/?name=dalquist
[14:33:52 CST(-0600)] <athena> oh interesting!
[14:33:54 CST(-0600)] <EricDalquist> and I'm going to try and copy how you have the portlet search working
[14:33:59 CST(-0600)] <athena> yeah, the renderer sounds like a terrific use case for that
[14:33:59 CST(-0600)] <EricDalquist> wellthat is just whitepages
[14:34:06 CST(-0600)] <athena> let me know if you have questions about it
[14:34:15 CST(-0600)] <EricDalquist> well a few right off the bat
[14:34:24 CST(-0600)] <EricDalquist> I'm guessing I should massage that JSON output a bit?
[14:34:26 CST(-0600)] <athena> i know fluid's also been updating their documentation, so i'm sure they'd be interested in any feedback you have
[14:34:37 CST(-0600)] <athena> depends
[14:34:42 CST(-0600)] <athena> you can, but you probably don't have to
[14:34:51 CST(-0600)] <EricDalquist> ok … let me get you my desired output
[14:35:24 CST(-0600)] <colinclark> That JSON seems relatively renderable
[14:35:28 CST(-0600)] <athena> the renderer is pretty flexible - trying to think of any good example code we have
[14:35:33 CST(-0600)] <colinclark> depending, as you say, on the output you want
[14:35:43 CST(-0600)] <EricDalquist> http://uportal.pastebin.com/KSwpyk6G
[14:35:57 CST(-0600)] <EricDalquist> the things I'm not clear on are how to deal with things like the email and phone arrays
[14:36:24 CST(-0600)] <EricDalquist> http://uportal.pastebin.com/HVFzhqeC
[14:36:32 CST(-0600)] <EricDalquist> so that is my first best guess at cutpoints
[14:36:40 CST(-0600)] <EricDalquist> also I'm not clear on how to deal with things like the email link
[14:36:54 CST(-0600)] <EricDalquist> in the portlet code the generated JSON model does:
[14:36:54 CST(-0600)] <EricDalquist> ID: "portletLink", linktext: portlet.title, target: "render.userLayoutRootNode.uP?uP_fname=" + portlet.fname
[14:37:25 CST(-0600)] <EricDalquist> and I'm guessing "linktext" and "target" are special key names that the renderer knows how to apply to an <a>
[14:37:41 CST(-0600)] <colinclark> yep
[14:37:43 CST(-0600)] <EricDalquist> if my json has "emails":["eric.dalquist@doit.wisc.edu"]
[14:38:02 CST(-0600)] <EricDalquist> how do I get that to render <a href="mailto:eric.dalquist@doit.wisc.edu">eric.dalquist@doit.wisc.edu</a>
[14:38:17 CST(-0600)] <athena> yeah, they are: http://wiki.fluidproject.org/display/fluid/Renderer+Component+Types
[14:39:05 CST(-0600)] <athena> so one key thing to know about the renderer is that those cutpoint that end in ":" get repeated
[14:39:16 CST(-0600)] <athena> so i fyou want to render more than one email address or phone number per user, you can do that
[14:39:48 CST(-0600)] <athena> in case you missed it:
[14:39:50 CST(-0600)] <athena> yeah, they are: http://wiki.fluidproject.org/display/fluid/Renderer+Component+Types
[14:39:50 CST(-0600)] <athena> 12:39
[14:39:50 CST(-0600)] <athena> so one key thing to know about the renderer is that those cutpoint that end in ":" get repeated
[14:39:55 CST(-0600)] <EricDalquist1> got it
[14:39:56 CST(-0600)] <EricDalquist1> ok
[14:40:03 CST(-0600)] <EricDalquist1> I made that assumption
[14:40:07 CST(-0600)] <athena> ok, good
[14:40:11 CST(-0600)] <EricDalquist1> what do I do if I just want the first one?
[14:40:20 CST(-0600)] <EricDalquist1> is my emails[0] the right guess?
[14:40:25 CST(-0600)] <colinclark> You can just use a path like this:
[14:40:27 CST(-0600)] <colinclark> "emails.0"
[14:40:30 CST(-0600)] <colinclark> you were close
[14:40:31 CST(-0600)] <EricDalquist1> ah
[14:40:37 CST(-0600)] <athena> neat
[14:40:53 CST(-0600)] <athena> there are a bunch of cool renderer tricks that i'm not actually very familiar with
[14:40:54 CST(-0600)] <EricDalquist1> and what about conditional content within the repeated block
[14:40:58 CST(-0600)] <athena> like all the exploding stuff
[14:41:02 CST(-0600)] <rickard> athena: Sorry to bug you, but I'm confused. I have method that has the ModelAttribute annotation so that I can do databinding from the view. But what if that method needs the PortletRequest? I can add it to the declaration, but will spring somehow automatically include it in the call? Am I making sense?
[14:41:15 CST(-0600)] <athena> yes, spring just magically does that
[14:41:16 CST(-0600)] <EricDalquist1> if you look at http://uportal.pastebin.com/KSwpyk6G
[14:41:19 CST(-0600)] <athena> and yes, you're making sense
[14:41:26 CST(-0600)] <EricDalquist1> there is a <div class="person_more"> block
[14:41:28 CST(-0600)] <rickard> Ah, magic
[14:41:32 CST(-0600)] <rickard> Thanks
[14:41:45 CST(-0600)] <athena> if you're building up the component tree manually, you can just add conditional logic to it
[14:41:52 CST(-0600)] <EricDalquist1> and I only want that to display if certain data is in the tree
[14:42:03 CST(-0600)]

[14:43:04 CST(-0600)] <athena> actually colinclark does eric want the "email.0" as the cutpoint? i think our general strategy is to usually bind the cutpoint to an id and then build the component tree manually w/ the actual data
[14:43:05 CST(-0600)] <EricDalquist1> colinclark: would it be better if I jumped in the fluid channel and picked brains there?
[14:43:19 CST(-0600)] <athena> but maybe there's a good strategy for doing this w/o all the manual code we've been writing?
[14:43:45 CST(-0600)] <EricDalquist1> so I'm not opposed to parsing the returned json and manipulating it into somethign the renderer can use
[14:44:25 CST(-0600)] <athena> what we've been doing is generally iterating through the json and building up a renderer-specific component tree
[14:44:32 CST(-0600)] <EricDalquist1> ok
[14:44:32 CST(-0600)] <athena> but i'm not sure that's actually the "right" strategy
[14:44:38 CST(-0600)] <EricDalquist1> right
[14:44:40 CST(-0600)] <athena> it certainly works, and most of the jasig code you'll see works that way
[14:44:51 CST(-0600)] <EricDalquist1> but I can see it being a little more straight forward if you're not really familiar with the renderer
[14:44:53 CST(-0600)] <athena> but i know some of the fluid examples seem a lot more magic
[14:45:01 CST(-0600)] <athena> yeah, i may just not understand that other stuff
[14:45:24 CST(-0600)] <jessm> EricDalquist1: the channel might be your best bet – we're doing QA on a release and everyone is listening in there
[14:45:40 CST(-0600)] <EricDalquist1> ok I'll go hijack your QA talk
[14:46:02 CST(-0600)] <athena> when you're done w/ that, i have a few more channel refactoring questions
[14:46:12 CST(-0600)] <colinclark> EricDalquist1: Sorry, I was away
[14:46:18 CST(-0600)] <EricDalquist1> no problem athena
[14:46:21 CST(-0600)] <EricDalquist1> I can multitask on that
[14:46:24 CST(-0600)] <colinclark> ah, you switched channels
[14:46:26 CST(-0600)] <EricDalquist1> so you ask channel refactoring here
[14:46:26 CST(-0600)] <athena> awesome
[14:46:34 CST(-0600)] <EricDalquist1> and I'll go ask fluid questions in the fluid channel
[14:46:45 CST(-0600)] <athena> so do we still need the isSecure() method on channels, and do we still need channel parameter overrides?
[14:46:58 CST(-0600)] <athena> i can't really even remember what isSecure does
[14:47:04 CST(-0600)] <athena> something about SSL maybe
[14:47:19 CST(-0600)] <EricDalquist1> no, portlets have secure URL flags bui;t in to the spec
[14:47:25 CST(-0600)] <athena> ok, that's what i thought
[14:47:33 CST(-0600)] <athena> assumed it was a similar use case
[14:47:46 CST(-0600)] <athena> do we have any reason to need param overrides anymoreO?
[14:49:29 CST(-0600)] <EricDalquist1> no
[14:49:34 CST(-0600)] <athena> excellent
[14:49:35 CST(-0600)] <athena>
[14:49:48 CST(-0600)] <athena> the last question i had was about creating new portlet definitions
[14:49:48 CST(-0600)] <EricDalquist1> once we convert channel params to layout params they won't really be user-overridable
[14:49:51 CST(-0600)] <EricDalquist1> though ...
[14:50:05 CST(-0600)] <athena> so what are those parameters going to be exactly?
[14:50:10 CST(-0600)] <athena> are they really layout params?
[14:50:29 CST(-0600)] <athena> or are they kind of just portlet definition parameters?
[14:52:19 CST(-0600)] <EricDalquist1> well we have portlet definition preferences
[14:52:24 CST(-0600)] <EricDalquist1> which appear in the portlet preferences
[14:52:39 CST(-0600)] <EricDalquist1> for a portlet the only thing channel parameters do right now is show up in the structure & theme XSL
[14:52:44 CST(-0600)] <athena> ok, gotcha
[14:52:48 CST(-0600)] <EricDalquist1> and we use them there for doing things like the icons
[14:52:51 CST(-0600)] <athena> right
[14:53:02 CST(-0600)] <athena> so they're kind of layout-related, but they're not user or instance-specific
[14:53:07 CST(-0600)] <athena> think we're on the same page
[14:53:11 CST(-0600)] <EricDalquist1> so I was thinking we just rename them from channel parameters to layout parameters
[14:53:12 CST(-0600)] <EricDalquist1> yup
[14:53:17 CST(-0600)] <athena> sure, no problem
[14:53:43 CST(-0600)] <athena> probably things like the application name and id are no longer parameters, i guess
[14:53:59 CST(-0600)] <EricDalquist1> right
[14:54:08 CST(-0600)] <EricDalquist1> they would just become fields on the portlet def
[14:54:12 CST(-0600)] <EricDalquist1> since you have to have those to be a portlet
[14:55:53 CST(-0600)] <athena> makes sense
[14:55:58 CST(-0600)] <athena> ok
[14:56:02 CST(-0600)] <athena> so for creating new portlet defs
[14:56:13 CST(-0600)] <athena> do we need a separate method for that from updating?
[14:56:18 CST(-0600)] <athena> not sure how we want that implemented
[14:57:14 CST(-0600)] <EricDalquist1> yeah, the way they have been modeled so far is the create method is like a constructor with required parameters
[14:57:37 CST(-0600)] <athena> ok, just wanted to make sure that's what we wanted to do
[14:57:40 CST(-0600)] <athena> that's what i've got so far
[14:57:50 CST(-0600)] <athena> and that doesn't need to do a persist?
[14:57:54 CST(-0600)] <EricDalquist1> so like the channel definition dao create method requires a few parameters, essentially the core of what is required for the definiton to exist
[14:58:03 CST(-0600)] <EricDalquist1> I think all the other cases we have it does
[14:58:46 CST(-0600)] <athena> ok
[14:58:51 CST(-0600)] <athena> no problem
[14:59:10 CST(-0600)] <athena> so it'd probably be a create and persist, then an update to set all the non-required fields
[14:59:13 CST(-0600)] <EricDalquist1> the reason is things can get harry if the DAOs pass back an un-attached DAO object and it isn't handled very carefully
[14:59:18 CST(-0600)] <EricDalquist1> yes
[14:59:38 CST(-0600)] <EricDalquist1> it only really results in one DB operation that happens at the end of the JPA session
[14:59:53 CST(-0600)] <EricDalquist1> but it guarantees that un-attached JPA objects are never being passed around
[15:00:09 CST(-0600)] <athena> yeah
[15:00:12 CST(-0600)] <athena> makes a lot of sense
[15:00:43 CST(-0600)] <EricDalquist1> the problem if you don't do that is the update() method then has to figure out if it is persisting a new object or updating an existing one
[15:00:50 CST(-0600)] <athena> right
[15:00:52 CST(-0600)] <EricDalquist1> and I don't think we ever found a non-expensive way of doing that
[15:02:26 CST(-0600)] <athena> makes sense
[15:02:39 CST(-0600)] <athena> i can probably get things compiling pretty soon
[15:02:43 CST(-0600)] <athena> will be the import that's a pain
[15:03:04 CST(-0600)] <EricDalquist1> yeah :/
[15:03:10 CST(-0600)] <athena> though i dunno, maybe it'd take me less time to do something that was exclusively java
[15:03:21 CST(-0600)] <athena> i don't understand some of our crn scripts as well as i should
[15:04:13 CST(-0600)] <EricDalquist1> if you have some time maybe a sandbox scratch project playing with JAXB and figuring out how we can do the id/fname replacement stuff
[15:04:28 CST(-0600)] <EricDalquist1> though for portlets I guess that isn't as big of a deal
[15:04:46 CST(-0600)] <athena> yeah, i'll play around w/ stuff
[15:05:02 CST(-0600)] <athena> maybe this could be a good intersection w/ the import/export portlet stuff i'd played with
[15:05:42 CST(-0600)] <EricDalquist1> yeah I really think JAXB + XSL could do some good things for us
[15:05:53 CST(-0600)] <EricDalquist1> we would need to actually write XSDs for all of our entity types
[15:05:57 CST(-0600)] <EricDalquist1> but that would be a good thing too
[15:06:22 CST(-0600)] <athena> yeah, it really would be
[15:06:26 CST(-0600)] <EricDalquist1> the only thing I'm not really sure about yet is the inter-object reference handling
[15:10:50 CST(-0600)] <athena> ah
[15:10:55 CST(-0600)] <athena> guess we can try it and see . . .
[15:10:58 CST(-0600)] <EricDalquist1> yeah
[15:11:05 CST(-0600)] <EricDalquist1> for portlet import export it probably won't be too bad
[15:11:23 CST(-0600)] <EricDalquist1> the other question is how to we handle things like categories & groups?
[15:11:44 CST(-0600)] <EricDalquist1> which are essentially object references
[15:11:58 CST(-0600)] <athena> yeah
[15:12:15 CST(-0600)] <athena> we'll have to think about how we want to represent this stuff in REST services too
[15:12:27 CST(-0600)] <EricDalquist1> yup
[15:12:33 CST(-0600)] <athena> don't know if it'll be the same as the import format or not
[15:12:40 CST(-0600)] <athena> would be kinda nice if it coudl be the same
[15:12:42 CST(-0600)] <EricDalquist1> so how do we import, export & handle REST calls
[15:12:44 CST(-0600)] <EricDalquist1> yeah
[15:12:45 CST(-0600)] <EricDalquist1> it would
[15:12:57 CST(-0600)] <EricDalquist1> can JAXB do JSON?
[15:13:19 CST(-0600)] <EricDalquist1> ohhh http://wiki.fasterxml.com/JacksonJAXBAnnotations
[15:13:51 CST(-0600)] <EricDalquist1> Jackson can deal with some of the JAXB annotations
[15:14:38 CST(-0600)] <athena> i think there's an option for JSON annotations
[15:14:40 CST(-0600)] <athena> forget what it is
[15:15:19 CST(-0600)] <athena> or i guess it's that
[15:15:48 CST(-0600)] <athena> ugh, looks like eclipse isn't properly doing an svn move when i renamed these classes
[15:15:52 CST(-0600)] <athena> how worried are we about that?
[15:16:04 CST(-0600)] <EricDalquist1> not really
[15:16:37 CST(-0600)] <athena> ok, i'll just carry on then
[15:16:45 CST(-0600)] <athena> these probably aren't classes that have a really interesting history anyway
[15:16:52 CST(-0600)] <EricDalquist1> yeah
[15:16:55 CST(-0600)] <athena> plus we're changing them so much
[15:17:14 CST(-0600)] <EricDalquist1> yup