[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)]