Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 29 Next »

[09:50:13 CST(-0600)] <EricDalquist> hey apetro, The logbot updates based on time and the ammount of traffic in the channel
[12:14:15 CST(-0600)] * esm (n=esm@clue.mse.jhu.edu) has joined ##uportal
[12:24:10 CST(-0600)] <esm> hey eric, i gotta finish up a couple of things and get some coffee but if you wanted to chat regarding preferences I should be "free" around 1:45 or 2 pm
[12:31:42 CST(-0600)] <EricDalquist> ok ... thats est?
[12:32:25 CST(-0600)] <esm> oh yeah est (smile) like in 30 minutes
[12:32:32 CST(-0600)] <esm> but if that isn't good for you that is fine
[12:32:47 CST(-0600)] <esm> i just need to get a couple of things out of the way before my afternoon is freed up
[12:33:04 CST(-0600)] <EricDalquist> lets say about an hour
[12:33:14 CST(-0600)] <EricDalquist> I'm working on getting the servant APIs all working
[12:33:49 CST(-0600)] <esm> ok no problem! I can get my meta-work done (writing documentation)
[13:31:19 CST(-0600)] <EricDalquist> looks like this servant stuff will take a little longer, 3pm EST still work for you?
[13:33:24 CST(-0600)] <esm> no problem eric whatsoever just ping me
[13:33:29 CST(-0600)] <EricDalquist> cool
[13:33:35 CST(-0600)] <esm> i've got stuff here to keep busy (smile)
[14:17:15 CST(-0600)] <EricDalquist> ok ...
[14:17:21 CST(-0600)] <EricDalquist> well I'm going to take a break from servants for a bit
[14:17:26 CST(-0600)] <EricDalquist> they're mostly working
[14:18:20 CST(-0600)] <EricDalquist> so ... whenever you're ready esm I can start brainstorming this portlet preference stuff
[14:19:00 CST(-0600)] <esm> ok let me get some coffee
[14:22:01 CST(-0600)] <EricDalquist> k
[14:26:34 CST(-0600)] <esm> ok back! i have my go go juice...
[14:26:41 CST(-0600)] <EricDalquist> (smile)
[14:27:05 CST(-0600)] <EricDalquist> so ... design issues around uP3 handles portlet preferences
[14:27:10 CST(-0600)] <esm> yes
[14:27:24 CST(-0600)] <EricDalquist> the spec defines deployment preferences (from portlet.xml)
[14:27:36 CST(-0600)] <EricDalquist> and entity preferences (that a user/running portlet modifies)
[14:27:51 CST(-0600)] <EricDalquist> at least deployment/entity are our names for those two levels
[14:27:58 CST(-0600)] <esm> Ok.
[14:28:12 CST(-0600)] <EricDalquist> we add a 3rd level in the middle of that, definition preferences
[14:28:20 CST(-0600)] <EricDalquist> these are defined when publishing a portlet
[14:28:35 CST(-0600)] <EricDalquist> gives an admin a way to configure defaults for a portlet
[14:28:44 CST(-0600)] <esm> gotcha
[14:28:52 CST(-0600)] <EricDalquist> so we have these three layers of data
[14:29:00 CST(-0600)] <EricDalquist> the portlet gets one, flat view of all of that data
[14:29:08 CST(-0600)] <esm> i follow so far
[14:29:22 CST(-0600)] <EricDalquist> with values from higher levels overriding values from lower levels
[14:29:28 CST(-0600)] <EricDalquist> thats all the easy part
[14:29:38 CST(-0600)] <EricDalquist> the hard part is how we deal with storing preferences
[14:29:53 CST(-0600)] <EricDalquist> the portlet manager has an easy time because it works directly with the uP3 OM
[14:30:01 CST(-0600)] <EricDalquist> and knows which preferences object to write to
[14:30:34 CST(-0600)] <EricDalquist> on the other had ... when a portlet gets its PortletPreferences, makes a bunch of mods, then calls store()
[14:30:40 CST(-0600)] <EricDalquist> it is a bit trickier
[14:31:04 CST(-0600)] <EricDalquist> we don't want to just store all the preferences at the entity level
[14:31:10 CST(-0600)] <EricDalquist> since that would hide administrative changes
[14:32:04 CST(-0600)] * esm digests
[14:33:37 CST(-0600)] <EricDalquist> so the pluto preferences service isn't very usefull because all we get from it is a flat array of InternalPreference objects and we have to do a bunch of figuring to determine which prefs to add/update/remove from the entity level by full comparisons and such
[14:34:19 CST(-0600)] <EricDalquist> after looking at the pluto apis last night I'm thinking what we need to do is provide custom RenderRequest/ActionRequest impls that return a custom uP3 PortletPreferences impl
[14:34:36 CST(-0600)] <EricDalquist> and our custom impl reads prefs from all 3 layers and just writes changes to the top layer
[14:35:57 CST(-0600)] <esm> yes i agree you will need a custom implementation
[14:36:32 CST(-0600)] <EricDalquist> ok .. so that all makes some semblance of sense
[14:36:42 CST(-0600)] <esm> yes that makes sense to me
[14:36:47 CST(-0600)] <EricDalquist> cool
[14:36:53 CST(-0600)] <EricDalquist> well thats the pluto side of it
[14:36:56 CST(-0600)] <esm> i have a question though about storing everything at the entity level
[14:37:01 CST(-0600)] <EricDalquist> ok
[14:37:54 CST(-0600)] <esm> you don't prefer to store everything at the entity level because later down the road you may want to change the value of that preference at a higher level.
[14:38:28 CST(-0600)] <EricDalquist> yeah
[14:38:55 CST(-0600)] <EricDalquist> so any preference not touched by the user/portlet can be changed by the admin and the user/portlet will see the change
[14:40:17 CST(-0600)] <esm> so if a user modifies a preference set at, say, the definition layer, you want the modification stored back at the definition layer instead of at the entity layer.
[14:40:44 CST(-0600)] <esm> cannot the code that retrieves a preference from the definition layer check the entity layer to see if it has been overridden?
[14:40:55 CST(-0600)] <EricDalquist> lets make sure we have terms right ... a user (via interacting with the portlet) stores preferences at the entity layer
[14:41:11 CST(-0600)] <esm> yes.
[14:41:12 CST(-0600)] <EricDalquist> an admin (via interacting with the portlet manager) stores preferences at the definition layer
[14:41:22 CST(-0600)] <esm> ok.
[14:41:55 CST(-0600)] <esm> what layer is used when a user modifies their layout and places a portlet? entity?
[14:42:53 CST(-0600)] <EricDalquist> heh ... windows are placed on a layout
[14:42:59 CST(-0600)] <EricDalquist> a window is backed by an entity
[14:43:05 CST(-0600)] <EricDalquist> an entity is backed by a definition
[14:43:13 CST(-0600)] <EricDalquist> and a definition is backed by a deployment
[14:43:58 CST(-0600)] <EricDalquist> in reality there is a 1 to 1 relationship between windows and entities
[14:44:11 CST(-0600)] <esm> example, say a simple portlet that consumes an rss feed. the rss feed url is a preference. the user goes into the channel manager to add the rss portlet to their layout and is prompted to enter a feed url before the portlet is put into their layout. that feed url is stored at entity
[14:44:12 CST(-0600)] <EricDalquist> so when you place a portlet a window and an entity is created
[14:44:19 CST(-0600)] <esm> right yes 1:1 entity to portlet window
[14:44:30 CST(-0600)] <EricDalquist> yes
[14:44:35 CST(-0600)] <esm> portlet window just has state attached to it like min vs max
[14:44:39 CST(-0600)] <EricDalquist> that is correct for your example
[14:44:39 CST(-0600)] <esm> modes
[14:44:41 CST(-0600)] <EricDalquist> yup
[14:44:42 CST(-0600)] <esm> ok
[14:46:04 CST(-0600)] <esm> so (i'm just trying to understand the use case) there are cases where upon an administrator defining a portlet, preferences are supplied by administrator
[14:46:21 CST(-0600)] <EricDalquist> yes
[14:46:22 CST(-0600)] <esm> heh my english is so bad
[14:46:31 CST(-0600)] <EricDalquist> me too (smile)
[14:46:42 CST(-0600)] <EricDalquist> so ... lets use the RSS feed again
[14:47:01 CST(-0600)] <esm> the preference value, if it isn't read-only, and if the portlet allows it to be edited, could be edited and saved by the user
[14:47:32 CST(-0600)] <EricDalquist> I publish an RSS portlet and point it to the University news feed, set the nubmer of articles to 5 and to show both title and summary
[14:47:43 CST(-0600)] <EricDalquist> a user subscribes to that RSS portlet
[14:47:52 CST(-0600)] <EricDalquist> the RSS portlet implements the EDIT mode
[14:48:23 CST(-0600)] <EricDalquist> the user goes in to edit and in the portlet rendered UI can change the number of articles and show title/summary options
[14:48:35 CST(-0600)] <EricDalquist> they change the options to show just the title
[14:48:39 CST(-0600)] <esm> ok
[14:48:51 CST(-0600)] <esm> (keep going i'm still here and following (smile)
[14:49:11 CST(-0600)] <EricDalquist> I go in to the portlet manager later and edit that same portlet I published and change the number of articles to 3
[14:49:36 CST(-0600)] <EricDalquist> I want that change to affect everyone that hasn't explicitly changed the number of articles setting
[14:49:50 CST(-0600)] <EricDalquist> I've been working with definition preferences via the portlet manager
[14:50:02 CST(-0600)] <EricDalquist> the user has been working with entity preferences via the edit UI of the portlet
[14:50:38 CST(-0600)] <esm> so the implementation that reads the preferences would: get the list of available preference names from the portlet definition, and then, starting at the lowest layer (entity) query for values.
[14:51:09 CST(-0600)] <EricDalquist> other way around ...
[14:51:17 CST(-0600)] <esm> and progressivly move up the layers looking for values that were not supplied by lower layers...
[14:51:20 CST(-0600)] <EricDalquist> it looks in entity first, then definition, then deployment (can
[14:51:22 CST(-0600)] <esm> oh well, right
[14:51:23 CST(-0600)] <EricDalquist> 't forget those)
[14:52:00 CST(-0600)] <esm> right
[14:52:45 CST(-0600)] <EricDalquist> dealing with all this internally has been a bit of a pain
[14:52:59 CST(-0600)] <EricDalquist> trying to balance not wanting to duplicate the layering logic all over
[14:53:18 CST(-0600)] <EricDalquist> and also wanting to make object & persistence management simple
[14:53:40 CST(-0600)] <esm> sorry i'm switching object models (smile) in pluto theres the ServletDefiinition -> portletapplicationdef -> portletdef -> portletentity -> portletwindow (i think)
[14:53:42 CST(-0600)] <esm> right
[14:53:54 CST(-0600)] <EricDalquist> yeah
[14:54:00 CST(-0600)] <EricDalquist> and what you call definitions we call deployments
[14:54:10 CST(-0600)] <esm> yes! that is where i was getting tripped up
[14:54:12 CST(-0600)] <EricDalquist> and definitions are what an administrator creates from a deployment
[14:54:42 CST(-0600)] <EricDalquist> then users subscribe to definitions (by getting an entity and window created)
[14:56:32 CST(-0600)] <EricDalquist> I'm also trying to figure out if we need to 'detach' the preferences from out definition & entity objects
[14:56:35 CST(-0600)] <esm> so ideally a uportal 3 persistance layer abstracts the layering away from your (or pluto's) preferences service
[14:58:18 CST(-0600)] <EricDalquist> yeah
[14:58:25 CST(-0600)] <EricDalquist> that part I'm not sure about
[14:59:12 CST(-0600)] <esm> are you not sure that you want the layering to be abstracted from preferences, or are you not sure about the implementation of the abstraction
[14:59:41 CST(-0600)] <esm> the implementation of the persistance abstraction
[14:59:59 CST(-0600)] <EricDalquist> the layering to be abstracted
[15:00:21 CST(-0600)] <EricDalquist> the hard part is the storing in the current impl
[15:01:18 CST(-0600)] <esm> sorry one sec
[15:01:19 CST(-0600)] <EricDalquist> so the deployment, definition, entity and window all have getPreferences() methods on them
[15:01:21 CST(-0600)] <EricDalquist> np
[15:02:56 CST(-0600)] <esm> ok right back
[15:03:23 CST(-0600)] <esm> er back
[15:03:30 CST(-0600)] <EricDalquist> bakc?
[15:03:41 CST(-0600)] <EricDalquist> (I can't type)
[15:03:42 CST(-0600)] <esm> back i mean i'm back from the phone
[15:03:46 CST(-0600)] <EricDalquist> ok
[15:03:53 CST(-0600)] <esm> we're both struggling (smile)
[15:03:56 CST(-0600)] <EricDalquist> (smile)
[15:04:11 CST(-0600)] <EricDalquist> this is going to be a fun log on confluence for someone to read
[15:04:23 CST(-0600)] <esm> (smile)
[15:04:26 CST(-0600)] <EricDalquist> so
[15:04:29 CST(-0600)] <EricDalquist> the uP3 OM
[15:04:32 CST(-0600)] <EricDalquist> the deployment, definition, entity and window all have getPreferences() methods on them
[15:04:38 CST(-0600)] <esm> so the deployment, definition, entity and window all have getPreferences() methods on them
[15:04:48 CST(-0600)] <esm> lol
[15:04:50 CST(-0600)] <EricDalquist> depending on which level you call it at you get a IPreferences interface
[15:05:05 CST(-0600)] <EricDalquist> which happens to be a LayeredPreferences impl
[15:05:15 CST(-0600)] <EricDalquist> which layers all the preferences from the lower levels into a unified view
[15:05:27 CST(-0600)] <EricDalquist> and changes are only made on the top of that view
[15:05:46 CST(-0600)] <EricDalquist> *to the top layer of that view
[15:05:55 CST(-0600)] <EricDalquist> sound good so far?
[15:06:23 CST(-0600)] <esm> top to bottom is deployment -> entity
[15:06:30 CST(-0600)] <EricDalquist> yup
[15:06:33 CST(-0600)] <esm> ok yeah
[15:06:40 CST(-0600)] <EricDalquist> and window has a getPreferences which just delegated to the entity right now
[15:06:51 CST(-0600)] <EricDalquist> in theory you could have window level preferences too ... scarry
[15:06:56 CST(-0600)] <esm> very
[15:07:11 CST(-0600)] <esm> so making sure i have this straight
[15:07:53 CST(-0600)] <esm> if I call getPreferences() on an entity, the IPreferences will only contain the preferences for the entity layer, since it is the lowest layer
[15:08:02 CST(-0600)] <EricDalquist> ah no
[15:08:09 CST(-0600)] <esm> ok
[15:08:36 CST(-0600)] <EricDalquist> if you call getPreferences() on an entity you get an object that internally layers the preferences from the entity, definition and deployment
[15:08:41 CST(-0600)] <esm> got it
[15:08:47 CST(-0600)] <esm> i am golden!
[15:08:51 CST(-0600)] <EricDalquist> when 'reading' from the object you get data from all 3
[15:09:04 CST(-0600)] <EricDalquist> when writing (set/reset) it just goes to the entity
[15:09:23 CST(-0600)] <EricDalquist> this makes things all nice and pretty for looking at the preferences and modifying them
[15:09:30 CST(-0600)] <EricDalquist> storing them is the trick
[15:09:37 CST(-0600)] <esm> got it. so if i call getPref() on a up 3 definition, i will get all three layers as well. above and below?
[15:09:46 CST(-0600)] <EricDalquist> nope
[15:09:49 CST(-0600)] <esm> DANG
[15:09:50 CST(-0600)] <EricDalquist> just below
[15:10:04 CST(-0600)] <EricDalquist> so entity.getPreferences() gives you entity on definition on deployment
[15:10:18 CST(-0600)] <EricDalquist> definition.getPreferences() gives you definition on deployment
[15:10:28 CST(-0600)] <EricDalquist> deployment.getPreferences() gives you deployment
[15:10:56 CST(-0600)] <esm> OK DANG thank you for spoon feeding me
[15:10:58 CST(-0600)] <EricDalquist> so objects in our OM can look to the root of the tree but not to the leaves
[15:11:01 CST(-0600)] <EricDalquist> np (smile)
[15:11:08 CST(-0600)] * esm removes spoon
[15:11:16 CST(-0600)] <esm> yes got it
[15:11:20 CST(-0600)] <EricDalquist> our OM is huge, and of course has confusing names wrt pluto
[15:11:23 CST(-0600)] <esm> for real.
[15:11:25 CST(-0600)] <esm> right
[15:11:52 CST(-0600)] <esm> so as you say, you currently have an implementation that works well for reading, but storing is a tricker issue.
[15:11:53 CST(-0600)] <EricDalquist> so, we're at the point where we get a 'nice' view of the preferences no matter where we are in the tree
[15:12:05 CST(-0600)] <EricDalquist> and the set/reset operations are nice too
[15:12:11 CST(-0600)] <EricDalquist> 'but storing that modified object is hard
[15:12:21 CST(-0600)] <EricDalquist> we obviously can't pass the layered IPreferences impl to the dao
[15:12:26 CST(-0600)] <EricDalquist> we just want to pass the top layer of it
[15:12:40 CST(-0600)] <esm> yes
[15:12:45 CST(-0600)] <EricDalquist> plus, we don't have a way right now to just store a IPreferences object
[15:13:02 CST(-0600)] <EricDalquist> if we got the object from the entity we actually have to store the whole entity
[15:13:20 CST(-0600)] <EricDalquist> so one part I'm thinking about doing is 'detaching' the preferences from the core om
[15:13:33 CST(-0600)] <EricDalquist> so they have their own registry & dao
[15:13:57 CST(-0600)] <EricDalquist> but I'm not sure that is worth it, or if it just won't make things more complicated
[15:14:01 CST(-0600)] <esm> yes that would be cleaner, being able to store preferences seperate from the entity.
[15:14:14 CST(-0600)] <EricDalquist> thats what I'm leaning towards too
[15:14:49 CST(-0600)] <EricDalquist> especially since the preferences could get modfied quite frequently by users and we really don't need to be worrying about storing the whole entity every time
[15:14:57 CST(-0600)] <esm> yes exactly
[15:15:11 CST(-0600)] <EricDalquist> (right now there is nothing stored in the entity except preferences but that can always change)
[15:15:15 CST(-0600)] * esm thinks
[15:16:37 CST(-0600)] <esm> i'm just pulling up the IPreferences interface now
[15:17:02 CST(-0600)] <EricDalquist> ok ... the version in the pluto1.1 branch is fairly different from the trunk/maven2 branch
[15:18:08 CST(-0600)] <esm> yeah that is what took the time (smile)
[15:18:21 CST(-0600)] <esm> just pulled the pluto integration branche from svn
[15:18:21 CST(-0600)] <EricDalquist> (smile)
[15:19:17 CST(-0600)] <esm> what dao is used?
[15:19:21 CST(-0600)] <esm> to store
[15:19:39 CST(-0600)] <esm> or you don't know yet
[15:19:47 CST(-0600)] <esm> wait you said entity
[15:19:50 CST(-0600)] <EricDalquist> yeah
[15:20:07 CST(-0600)] <EricDalquist> so if a user edits preferences we use an IEntityRegistry and call store
[15:21:10 CST(-0600)] <EricDalquist> if you have the latest uP3-pluto code take a look at PortletPreferencesServiceImpl
[15:21:37 CST(-0600)] <EricDalquist> this handles reading & adding preferences correctly but not reseting (my quick hack to get portlets rendering in uP3)
[15:21:38 CST(-0600)] <esm> ok (i do have the latest)
[15:21:53 CST(-0600)] <EricDalquist> btw getting this fixed and servants fixed should be my last tasks on the pluto 1.1 branch
[15:22:03 CST(-0600)] <EricDalquist> so I'm right on schedule for merging back into the trunk
[15:22:07 CST(-0600)] <esm> NICE
[15:22:26 CST(-0600)] <esm> i've been in pluto-land working on 1.1.1 so less time with up3. hopefully this weekend i can pick back up
[15:22:43 CST(-0600)] <EricDalquist> np
[15:22:52 CST(-0600)] <EricDalquist> my wife will be at class all day saturday
[15:22:53 CST(-0600)] <esm> so IPortletEntityTransfer is interesting
[15:23:05 CST(-0600)] <EricDalquist> so I'll probably finish up up3/pluto then and start looking @ maven
[15:23:12 CST(-0600)] <esm> cool
[15:23:17 CST(-0600)] <EricDalquist> ah and then that is the other big seperation we have
[15:23:26 CST(-0600)] <EricDalquist> *Transfer objects move between DAOs and Registries
[15:23:30 CST(-0600)] <esm> in general when you persist
[15:23:31 CST(-0600)] <esm> ok
[15:23:50 CST(-0600)] <EricDalquist> the non transfer objects (our 'public' OM) move between Registries and framework code
[15:24:20 CST(-0600)] <esm> so the registriy is responsible for creating the transfer object?
[15:25:40 CST(-0600)] <EricDalquist> daos create the transfer objects
[15:25:53 CST(-0600)] <esm> right yes just saw IPortletEntityDao.createPortletEntity
[15:25:54 CST(-0600)] <esm> (smile)
[15:26:06 CST(-0600)] <esm> er
[15:26:09 CST(-0600)] <esm> *get
[15:26:23 CST(-0600)] <EricDalquist> so if you want a IPortletEntity you ask the IPortletEntityRegistry, it looks in a cache and if not their talks to the DAO, gets the transfer and other dependend objects and returns a constructued IPortletEntity
[15:27:26 CST(-0600)] <esm> i'm at a disadvantage because I don't know the code very well, but
[15:28:02 CST(-0600)] <EricDalquist> np, I really appreciate the time, effort and opinion on this
[15:28:22 CST(-0600)] <esm> a) I guess you can add methods to IPreference to let the DAO find out what layer it is from
[15:28:25 CST(-0600)] <esm> kind of ugly
[15:28:54 CST(-0600)] <esm> b) have marker interfaces indicating the layer and use instanceof in the DAO
[15:28:59 CST(-0600)] <esm> also kind of ugly
[15:29:56 CST(-0600)] <esm> c) provide the DAO with some object responsible for determining the layer to store a preference at
[15:31:03 CST(-0600)] <EricDalquist> just a sec
[15:31:33 CST(-0600)] <esm> or, thinking out of the box, turn this problem around and give the Preference a DAO instance
[15:34:54 CST(-0600)] <esm> a dao instance or an object which can get it a DAO instance.
[15:35:39 CST(-0600)] <EricDalquist> I was thinking along the lines of d) as well
[15:35:55 CST(-0600)] <EricDalquist> I remove the getPreferences() from the domain objects
[15:36:03 CST(-0600)] <EricDalquist> create a prefernces dao and preferences registry
[15:36:14 CST(-0600)] <EricDalquist> have the same transfer object / domain object seperations
[15:36:41 CST(-0600)] <EricDalquist> and the preferences domain object contains the layering logic and the correct information for handling the store() call
[15:39:24 CST(-0600)] <EricDalquist> thoughts on that?
[15:41:02 CST(-0600)] <esm> the prefernces registry would return a preferences xfer object?
[15:42:18 CST(-0600)] <EricDalquist> the pref dao would return the xfer object to the registry
[15:42:27 CST(-0600)] <EricDalquist> and the registry would return a domain object to framework code
[15:42:34 CST(-0600)] <EricDalquist> the xfers are just pojos
[15:42:47 CST(-0600)] <EricDalquist> the domain objects generally have logic and such internally
[15:43:29 CST(-0600)] <esm> ok cool. so when the registry constructs the preference domain object, it would give it an instance of the dao?
[15:43:46 CST(-0600)] <EricDalquist> probably a reference to itself
[15:43:52 CST(-0600)] <esm> ah ok sure
[15:44:08 CST(-0600)] <EricDalquist> so the store goes through the registry to make sure the cache is updated
[15:44:12 CST(-0600)] <esm> yeah I think that solves the problem neatly
[15:44:14 CST(-0600)] <esm> exactly!
[15:44:18 CST(-0600)] <EricDalquist> cool
[15:44:26 CST(-0600)] <esm> at the cost of some more code (smile)
[15:44:33 CST(-0600)] <esm> but it uses existing patterns present in up 3
[15:44:38 CST(-0600)] <esm> so it should be easy to grok
[15:44:39 CST(-0600)] <EricDalquist> well I may wait on that exact solution until we get into the maven2 stuff
[15:44:45 CST(-0600)] <esm> sure
[15:44:46 CST(-0600)] <EricDalquist> just because it is a fair ammount of code
[15:44:49 CST(-0600)] <EricDalquist> but we'll see
[15:44:56 CST(-0600)] <EricDalquist> I'll fix this servant stuff and see where I am
[15:45:20 CST(-0600)] <esm> i had a question but now i forget...
[15:45:44 CST(-0600)] <EricDalquist> (smile)
[15:46:52 CST(-0600)] <esm> well never mind. but i have another question
[15:47:04 CST(-0600)] <esm> related to preferences
[15:47:29 CST(-0600)] <EricDalquist> ok
[15:48:21 CST(-0600)] <esm> back to the rss portlet example. I have three instances of that portlet in my layout, but each instance has a distinct value for the feed it is consuming
[15:48:43 CST(-0600)] <EricDalquist> ok
[15:48:57 CST(-0600)] <esm> in the up 3 object model those three instances are backed by three distict portlet windows which are one to one with portlet entities
[15:49:06 CST(-0600)] <EricDalquist> yes
[15:49:30 CST(-0600)] <esm> anyway so there are three distinct sets of preferences stored
[15:49:45 CST(-0600)] <EricDalquist> yes
[15:49:46 CST(-0600)] <esm> ok
[15:50:25 CST(-0600)] <EricDalquist> in theory they could be three different definitions that the admin setup, or one definition that you subscribed to and customized three times
[15:50:31 CST(-0600)] <EricDalquist> or some combination along those lones
[15:50:33 CST(-0600)] <EricDalquist> lines*
[15:50:41 CST(-0600)] <esm> right ok
[15:53:09 CST(-0600)] <EricDalquist> I really need to find a good way to diagram our transfer and domain object models
[15:53:31 CST(-0600)] <esm> so as a result of refactoring the preferences as discussed above, you won't have to provide a customized preferences implementation to pluto right?
[15:53:41 CST(-0600)] <EricDalquist> no I still will
[15:53:59 CST(-0600)] <EricDalquist> since with the prefsservice I just provide/get and array of preference objects
[15:54:08 CST(-0600)] <EricDalquist> no layering options at all
[15:54:56 CST(-0600)] <esm> ah right ok
[15:55:22 CST(-0600)] <EricDalquist> I might look at writing a patch for 1.2
[15:55:26 CST(-0600)] <esm> you had a nice graphic at the fall (question) jasig conference when you and peter presetned on up3
[15:55:32 CST(-0600)] <EricDalquist> yeah
[15:55:35 CST(-0600)] <EricDalquist> something more complete though
[15:55:48 CST(-0600)] <esm> right, more "zoomed in" on particular portions of the graphic
[15:56:03 CST(-0600)] <EricDalquist> yeah
[15:56:25 CST(-0600)] <esm> well thanks for helping me understand more about uportal's guts (smile)
[15:56:29 CST(-0600)] <EricDalquist> np
[15:56:35 CST(-0600)] <EricDalquist> thanks for the input on all this stuff
[15:56:42 CST(-0600)] <EricDalquist> it really helps to get another view of it
[15:57:12 CST(-0600)] <esm> it is nice to have someone to push back at you regarding a design.
[15:57:36 CST(-0600)] <esm> hopefully as i get more into it these conversations will be shorter (b/c i'll be more familiar with the issues/code)
[15:57:42 CST(-0600)] <EricDalquist> (smile)
[15:57:44 CST(-0600)] <esm> i need to switch jobs faster
[15:57:53 CST(-0600)] <EricDalquist> ?
[15:58:03 CST(-0600)] <esm> i'm moving into a programming positiiton, i'm in a sysadmin position now
[15:58:08 CST(-0600)] <EricDalquist> ah
[15:58:09 CST(-0600)] <esm> but HR is being really slow
[15:58:40 CST(-0600)] <esm> and so right now I'm trying juggle the resopnsiblilties of both positions without really being able to be effective at one or the other
[15:58:52 CST(-0600)] <EricDalquist> uhg
[15:59:22 CST(-0600)] <esm> yeah. two days ago i got a "heads up" that we need to migrate our sakai installation to another server!!!!
[15:59:27 CST(-0600)] <EricDalquist> so does JHU have an interest in uP3 or is this more because of your pluto involvement
[15:59:30 CST(-0600)] <EricDalquist> that sounds like fun
[16:00:03 CST(-0600)] <esm> no we have interest in up3. i got into pluto because up2 was running with a pluto 1.0.x release candidate and half of my portlets weren't working
[16:00:13 CST(-0600)] <EricDalquist> (smile)
[16:00:55 CST(-0600)] <esm> so we are on up 2.5.2 right now, + patches. I'm trying to convince our central it group to take a deepr look at up3
[16:01:06 CST(-0600)] <EricDalquist> that would be great
[16:01:13 CST(-0600)] <esm> they are kind of struggling right now with "strategy"
[16:01:16 CST(-0600)] <EricDalquist> what layout manager are you using in 2.5?
[16:01:20 CST(-0600)] <esm> DLM
[16:01:33 CST(-0600)] <EricDalquist> yeah, thats going to be the big thing in another few months
[16:01:39 CST(-0600)] <EricDalquist> getting something like DLM in uP3
[16:02:11 CST(-0600)] <esm> when we were considering implementing uportal, we picked 2.5 over 2.4 (2.5 had just gone to GA at the time) explicitly because of DLM
[16:02:25 CST(-0600)] <EricDalquist> makes sense
[16:02:31 CST(-0600)] <EricDalquist> DLM is very powerfull
[16:02:56 CST(-0600)] <esm> yeah but is crippled somewhat by the relative pain to modify your layout
[16:03:02 CST(-0600)] <EricDalquist> yeah
[16:03:09 CST(-0600)] <EricDalquist> for end user's you mean?
[16:03:12 CST(-0600)] <esm> right
[16:03:13 CST(-0600)] <esm> yes
[16:04:49 CST(-0600)] <esm> so the push to get up3 developers meeting at JHU has some political undercurrent here at JHU. the guys in the central IT department are, lets say, unfamiliar, with community or open source
[16:05:01 CST(-0600)] <EricDalquist> cool
[16:05:17 CST(-0600)] <EricDalquist> well I'm supposed to be writing something up to try and make wednesday a up3 primer at the deve meeting
[16:05:33 CST(-0600)] <esm> it is rare that you can pull open source enterprise software off the shelf (e.g., download from sourceforge) and get everything you want without participating in the community. so i'm trying to get them to participate.
[16:05:46 CST(-0600)] <esm> very cool
[16:06:00 CST(-0600)] <EricDalquist> yeah
[16:06:07 CST(-0600)] <EricDalquist> well you writing code is a big +
[16:06:27 CST(-0600)] <esm> even if they (JHU central it) eventually opt out of uPortal, thats ok. I like the community and will still participate just as much as I am now if not more.
[16:06:41 CST(-0600)] <EricDalquist> just knowing we have that interest is a help, makes me start wanting to plan things ... like a UW/JHU authored DLM for uP3 being written this summer
[16:07:25 CST(-0600)] <esm> my group (the library) is defintly open-source aware and fosters/subsidizes us to work with those communiities.
[16:07:30 CST(-0600)] <esm> yeah (smile)
[16:07:34 CST(-0600)] <esm> we need dlm for up3
[16:08:08 CST(-0600)] <esm> i'd like our guys to check out jen's ajax stuff
[16:08:22 CST(-0600)] <esm> but right now they are busy re-architecting the portal infrastructure
[16:08:37 CST(-0600)] <EricDalquist> ah
[16:09:00 CST(-0600)] <esm> they just don't have a streamlined way of upgrading and patching uportal
[16:09:09 CST(-0600)] <EricDalquist> yeah that can be hard
[16:09:13 CST(-0600)] <EricDalquist> we have a lot of customizations
[16:09:21 CST(-0600)] <EricDalquist> and merging vendor branches it a lot of work
[16:09:25 CST(-0600)] <EricDalquist> that is part of the hope with uP3
[16:09:28 CST(-0600)] <esm> yeah. it is hard, but the problem has been solved by a number of institutions.
[16:09:32 CST(-0600)] <EricDalquist> people don't modify existing code
[16:09:41 CST(-0600)] <esm> yes, hopefuly with up3 you can just plug in an implementation
[16:09:42 CST(-0600)] <EricDalquist> they just re-impl the bits they need changed
[16:09:43 CST(-0600)] <esm> or extend
[16:09:44 CST(-0600)] <esm> right
[16:09:49 CST(-0600)] <EricDalquist> and all they have to deal with merging is spring configs
[16:11:05 CST(-0600)] <EricDalquist> well I'm excited to get started on this maven stuff
[16:11:20 CST(-0600)] <EricDalquist> I really want to get things nicely seperated and have a well defined dependency graph
[16:11:47 CST(-0600)] <esm> YES YES
[16:11:59 CST(-0600)] <esm> I cannot wait. up3 will be sooooo much better off
[16:12:29 CST(-0600)] <EricDalquist> yeah
[16:12:38 CST(-0600)] <esm> and then, after maven refactoring, we have a solid base which we can use to implement the missing features
[16:12:42 CST(-0600)] <EricDalquist> yup
[16:12:46 CST(-0600)] <esm> or fill in the gaps of existing features
[16:12:47 CST(-0600)] <esm> yes
[16:13:04 CST(-0600)] <esm> and then ship the bad boy
[16:13:05 CST(-0600)] <EricDalquist> for the dev meeting I want to have some good talks about pojo <-> xml frameworks
[16:13:11 CST(-0600)] <EricDalquist> so we can get rid of data.xml and dbloader
[16:13:17 CST(-0600)] <esm> excellent yes that sounds good
[16:13:38 CST(-0600)] <EricDalquist> my goal is for the spring conference to have uP3 to a point where you just need to do a svn checkout
[16:13:48 CST(-0600)] <EricDalquist> change the db config
[16:14:00 CST(-0600)] <EricDalquist> run mvn package
[16:14:04 CST(-0600)] <EricDalquist> deploy the EAR
[16:14:06 CST(-0600)] <EricDalquist> and go
[16:14:11 CST(-0600)] <EricDalquist> no initportal
[16:14:13 CST(-0600)] <EricDalquist> no initdb
[16:14:15 CST(-0600)] <EricDalquist> none of that
[16:14:18 CST(-0600)] <esm> yeah
[16:14:28 CST(-0600)] <esm> up3 needs a maven plugin to do that stuff
[16:14:35 CST(-0600)] <esm> if all it does is wrap the ant task
[16:14:40 CST(-0600)] <EricDalquist> yeah
[16:14:52 CST(-0600)] <esm> shoudl we start sub-wiki pages on agenda topics in the wiki
[16:15:03 CST(-0600)] <esm> thoughts for example on xml databinding/serialization
[16:15:05 CST(-0600)] <EricDalquist> that will start soon
[16:15:07 CST(-0600)] <esm> ok

  • No labels