uPortal IRC Logs-2006-10-02

[08:44:14 CDT(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[09:51:06 CDT(-0500)] * peterk (i=[U2FsdGV@66.226.77.81) has joined ##uportal
[09:51:59 CDT(-0500)] <EricDalquist> good morning
[09:53:19 CDT(-0500)] <peterk> morning
[09:53:28 CDT(-0500)] <EricDalquist> I have a question about stylesheet rendering attributes in the up2 context
[09:53:44 CDT(-0500)] <peterk> shoot
[09:53:59 CDT(-0500)] <EricDalquist> I'm working on the issue to get the WindowStates/PortletModes synced up with the layout
[09:54:50 CDT(-0500)] <EricDalquist> how do I get a IRequestParameterProcessor to influence the structure and theme transforms?
[09:55:17 CDT(-0500)] <EricDalquist> should I create another IRequestParameterProcessor for the uP2 context that exposes methods for modifying the nessesary XSL parameters?
[09:55:56 CDT(-0500)] <peterk> there is a uP2-specific request parameter processor already .. that does some minor tasks custom to the context
[09:56:29 CDT(-0500)] <peterk> do you think the methods would be general enough so we would include those in uP3 context?
[09:57:32 CDT(-0500)] <EricDalquist> hrm, they could be, it would be things along the lines of "set PortletMode to X on portlet Y
[09:58:05 CDT(-0500)] <peterk> why is this related to the theme/structure transforms?
[09:58:20 CDT(-0500)] <peterk> it normally goes through portlet window manager
[09:58:25 CDT(-0500)] <peterk> and then to Pluto
[09:58:35 CDT(-0500)] <EricDalquist> well the portlet side of it is fine
[09:58:49 CDT(-0500)] <EricDalquist> but the chrome around the portlet doesn't reflect minmize/maximize states
[09:59:20 CDT(-0500)] <EricDalquist> and using the chrome buttons doesn't currently affect the portlet's state at all
[09:59:25 CDT(-0500)] <peterk> so what you probably want is some way of injecting that information into the xml stream, instead of having to pass another request param
[09:59:35 CDT(-0500)] <EricDalquist> yeah
[09:59:44 CDT(-0500)] <EricDalquist> if that is the more appropriate way of doing it
[10:01:08 CDT(-0500)] <peterk> so then you need a custom sax rendering component that would inject that info
[10:01:17 CDT(-0500)] <EricDalquist> ok
[10:01:51 CDT(-0500)] <peterk> you may be able to reuse rendering attriubte injector interface for that purpose, but it's not really designed for that
[10:02:34 CDT(-0500)] <EricDalquist> ok, and what about the other way, catching XSL rendering attributes from the URL and affecting a portlet with them
[10:02:47 CDT(-0500)] <EricDalquist> you said there is already a param processor doing some of that?
[10:02:56 CDT(-0500)] <peterk> bad idea - we want only one place in the code to process that url syntax
[10:03:07 CDT(-0500)] <peterk> there is, it's portlet syntax processor
[10:03:24 CDT(-0500)] <EricDalquist> well we have two ways to control this state
[10:03:38 CDT(-0500)] <EricDalquist> the portlet can change states and modes via URLs it renders
[10:03:49 CDT(-0500)] <EricDalquist> and the portlet can have states and modes changed on it via chrome
[10:04:05 CDT(-0500)] <EricDalquist> which are XSL parameters in the uP2 context
[10:04:08 CDT(-0500)] <peterk> I think it can request to change it internally too during action
[10:04:31 CDT(-0500)] <peterk> there are two ways for implementing the later option
[10:04:33 CDT(-0500)] <EricDalquist> yeah thats true
[10:04:37 CDT(-0500)] <EricDalquist> so three ways
[10:04:52 CDT(-0500)] <peterk> 1: keep the existing url syntax (from uP2), and write a custom processor to parse it out and talk to portlet window manager to set the new mode
[10:04:52 CDT(-0500)] <EricDalquist> and we need to ensure the XSL's parameters and the portlet's state is kept in sync
[10:05:02 CDT(-0500)] <EricDalquist> this is a really vexing issue in up2
[10:05:18 CDT(-0500)] <peterk> 2: use xslt extension elements within uP2 stylesheet to generate standard portlet mode changing urls
[10:05:56 CDT(-0500)] <peterk> either way is fine I think
[10:05:59 CDT(-0500)] <EricDalquist> I'm thinking we should go with 1 since we want to minimize nessesary changes to the uP2 XSL?
[10:06:13 CDT(-0500)] <peterk> yah, but no-one seems to be impressed with that so far
[10:06:26 CDT(-0500)] <EricDalquist>
[10:06:33 CDT(-0500)] <peterk> I guess we might as well keep doing it, since we've done all the other stuff this way
[10:06:51 CDT(-0500)] <peterk> but you still need that xml injector that would inform the transform about current mode/available modes, etc.
[10:07:37 CDT(-0500)] <EricDalquist> ok, so I'll create a processor to watch for mode/state changes and apply them to the portlet and a XML injector that informs the transform about the current modes/states for all rendering portlets to ensure the layout and portlets are always in sync
[10:08:44 CDT(-0500)] <peterk> right ... in that injector - do a good job on caching keys
[10:08:57 CDT(-0500)] <peterk> because it will be upstream of at least one transform
[10:09:15 CDT(-0500)] <peterk> and if it doesn't cache efficiently, it will be a performance hit downstream
[10:09:34 CDT(-0500)] <EricDalquist> ok, when I get to that point I'll come back for some consultation on cache key generation
[10:10:33 CDT(-0500)] <peterk> and for the processor - you can probably work that functionality into uPortal2TransformationInformationProvider that's currently configured in the context - it doesn't have clear functional purpose
[10:10:53 CDT(-0500)] <EricDalquist> ok
[11:24:17 CDT(-0500)] * deuce_ (n=deuce@uni1.unicon.net) has joined ##uportal
[11:27:42 CDT(-0500)] <EricDalquist> hey deuce_ what login id do you use in the jasig jira?
[11:29:32 CDT(-0500)] <deuce_> let consult my keychain
[11:30:43 CDT(-0500)] <deuce_> nbolton
[11:31:11 CDT(-0500)] <EricDalquist> cool
[11:31:20 CDT(-0500)] <EricDalquist> I'll consolodate your accounts later today
[11:31:25 CDT(-0500)] <deuce_> thx
[11:39:07 CDT(-0500)] * deuce_ (n=deuce@uni1.unicon.net) has joined ##uportal
[11:42:45 CDT(-0500)] <peterk> morning Nick
[11:43:08 CDT(-0500)] <deuce_> mornin, peter
[11:43:16 CDT(-0500)] <deuce_> how goes it
[11:44:20 CDT(-0500)] <peterk> pretty good, thanks. I've checked in that change to gap dbinit config, so it reuses the webapp config
[11:46:09 CDT(-0500)] <peterk> also makes for easy unit test config ... I checked those in. They work just fine under eclipse junit starter, but I couldn't get them to work in runtests ant task - must be something to do with the classpath - I added web-inf folder to tests.classpath, but I don't think it works (may be because WEB-INF/classes is already in it?)
[11:48:34 CDT(-0500)] <deuce_> hmmm you should be able to include nested directories in the classpath
[11:49:55 CDT(-0500)] <peterk> I thought so too, but eclipse gave me an error like that when I tried to include both webapp/ and webapp/dtds/ ... anyhow, I haven't actually had a chance to look into the logs during ant runtests.
[11:50:52 CDT(-0500)] <deuce_> ok. i guess we'll just add it to the sprint backlog
[11:52:07 CDT(-0500)] <peterk> there's already a task there for cleaning up unit tests, right?
[11:52:41 CDT(-0500)] <deuce_> perhaps if so, we can just tack it on
[12:38:32 CDT(-0500)] * deuce_ (n=deuce@uni1.unicon.net) has joined ##uportal
[12:47:04 CDT(-0500)] * deuce_ (n=deuce@uni1.unicon.net) has joined ##uportal
[12:54:46 CDT(-0500)] * deuce_ (n=deuce@uni1.unicon.net) has joined ##uportal
[13:29:50 CDT(-0500)] <EricDalquist> peterk Before I go digging in the code would there be a fairly easy way for a IRequestParameterProcessor to determine what the nodeId is of the portlet that is currently focused in the style sheet?
[13:34:04 CDT(-0500)] <peterk> hmm .. focus mode right now is left to the stylesheet (structure stylesheet), so it's just an XSL param.
[13:34:16 CDT(-0500)] <peterk> which means it may change from one stylesheet to another
[13:34:35 CDT(-0500)] <peterk> we probably could standardize on some
[13:35:15 CDT(-0500)] <peterk> now if you wanted to get the value, you can do it by quering the structure rendering attribute provider
[13:35:20 CDT(-0500)] <EricDalquist> hrm ... the issue I have is when a user clicks on a link with the parameters "uP_root=root" to go back from a Maximized portlet to a Normal portlet I don't know which portlet to make the change on
[13:35:26 CDT(-0500)] <EricDalquist> ok
[13:35:33 CDT(-0500)] <EricDalquist> thats probably what I need to do
[13:36:03 CDT(-0500)] <peterk> hmm .. let me look. there was also root param for the layout manager (although I don't think that was ever used)
[13:36:24 CDT(-0500)] <EricDalquist> brb
[13:39:35 CDT(-0500)] <peterk> check out TransformationFilterLegacyRequestParameterProcessor:95 - that's where that focus param is being processed
[13:41:08 CDT(-0500)] <peterk> it's being set on structure stylesheet rendering attribute provider
[13:42:08 CDT(-0500)] <peterk> if you choose to inject that provider into your processor, you'll have to place your processor after transformationParameterProcessor
[13:42:27 CDT(-0500)] <peterk> in the context spring config that is
[13:44:47 CDT(-0500)] <EricDalquist> ok, thanks for the info
[14:06:21 CDT(-0500)] <EricDalquist> is there ever a case where multiple portlets could have their PortletMode/WindowStates changed at the same time?
[14:11:39 CDT(-0500)] <peterk> well, uportal doesnt' restrict that
[14:12:12 CDT(-0500)] <peterk> but if you're processing uP2 syntax that comes from the stylesheet - that shouldn't happen
[15:09:02 CDT(-0500)] * shawnlonas (n=shawn@uni1.unicon.net) has joined ##uportal
[15:12:08 CDT(-0500)] * peterk_ (i=[U2FsdGV@66.226.77.81) has joined ##uportal
[15:51:28 CDT(-0500)] * deuce (n=deuce@uni1.unicon.net) has joined ##uportal
[16:22:27 CDT(-0500)] <EricDalquist> is there a reason for having a number of duplicate Mock objects in org.jasig.portal.mock and org.jasig.portal.layout.uportal2.simple?
[16:22:39 CDT(-0500)] <EricDalquist> I didn't look really closely but they all look to be pretty much the same
[16:32:03 CDT(-0500)] <peterk_> Eric: some of them could be just duplicated, others may have different set/get methods
[16:34:36 CDT(-0500)] <peterk> Eric: another thing related to portlet modes config that we need to figure out is how subscribe-time portlet preferences will be managed. we've discussed this briefly at the dev. meeting, but without a good solution.
[16:35:37 CDT(-0500)] <EricDalquist> ah yeah
[16:35:45 CDT(-0500)] <EricDalquist> as to that I'm not sure
[16:36:35 CDT(-0500)] <EricDalquist> perhaps some sort of 'prompt at subscribe' flag that can be set on portlet preferences to tell the container which ones to prompt for?
[16:36:50 CDT(-0500)] <EricDalquist> and then a edit defaults button to get back to change them?
[16:36:51 CDT(-0500)] <peterk> the reason I am bringing this up because this could be another option for mapping edit mode (i.e to a portal-provided "edit subscribe-time preferences" screen)
[16:37:15 CDT(-0500)] <peterk> I think the UI guys will shoot us if we do "prompt at subscribe", although I can see use for that
[16:37:55 CDT(-0500)] <peterk> (on edit mode - portlets may have their own mode that would map to an edit control)
[16:38:49 CDT(-0500)] <EricDalquist> yeah that could be a way to do it
[16:39:48 CDT(-0500)] <EricDalquist> so you have the option of no edit button on the chrome, an edit button on the chrome that goes to PortletMode.EDIT for the portlet or an edit button on the chrome that goes to a container rendered screen to edit designated portlet preferences
[16:40:25 CDT(-0500)] <EricDalquist> that sounds like a trap in the code just before the portlet gets added to the rendering pool
[16:41:28 CDT(-0500)] <peterk> right
[16:41:39 CDT(-0500)] <peterk> where are you storing these mappings?
[16:42:57 CDT(-0500)] <EricDalquist> I think the PortletMode and WindowState mappings are part of the portlet definition object right now
[16:43:33 CDT(-0500)] <peterk> and "prompt at subscribe" could be yet another option, and portal would keep a flag that would cause the preferences screen to render instead of the portlet (alternative implementation would be to query for these params in the subscription portlet when user initiates subscribe action)
[16:44:18 CDT(-0500)] <EricDalquist> oh no, actually PortletMode and WindowState mappings are part of the PortletApplicationDefinition
[16:44:29 CDT(-0500)] <EricDalquist> so I would need to add this into the Portlet side of the portlet manager
[16:44:58 CDT(-0500)] <EricDalquist> and they need a storage location
[16:45:13 CDT(-0500)] <EricDalquist> but so do the flags for showing Edit/Help/Min/Max buttons
[16:45:36 CDT(-0500)] <EricDalquist> I think all of those fall into the portlet rendering attribute category?
[16:50:52 CDT(-0500)] <EricDalquist> so I have half this portlet mode/state code done, dealing with the URL parameters
[16:51:06 CDT(-0500)] <EricDalquist> now I'm looking at enforcing portlet state on the rendered XSL
[16:52:04 CDT(-0500)] <EricDalquist> I'm thinking I need something in the SAX filter chain pre-structure transform that will look at the state&mode of each portlet in the layout and set the appropriate parameters on the structure via the structure's IRenderingAttributeProvider?
[16:54:25 CDT(-0500)] <peterk> why on the structure ?
[16:54:53 CDT(-0500)] <peterk> these are not structure-stylesheet defined attributes - they are properties of the portlet windows (or entites) right?
[16:55:57 CDT(-0500)] <EricDalquist> they are properties of PortletWindows but I need to translate those properties into the appropriate stylesheet parameters so the stylesheet rendered chrome matches the state of the PortletWindow
[16:57:14 CDT(-0500)] <peterk> so I guess it's a question of whether we want to write a custom filter that would matche the syntax of an existing stylesheet, or change the stylesheet to support a re-usable filter. I your alternative is correct since we're trying to minimize the changes to the stylesheet
[16:58:08 CDT(-0500)] <peterk> however do you intend to persist flags for showing Edit/Help/etc. buttons as structure rendering attributes as well?
[16:58:27 CDT(-0500)] <peterk> because that wouldn't work - they persisted values would change when the structure stylesheet would change
[16:58:41 CDT(-0500)] <EricDalquist> I don't think so since they aren't persisted in uP2 right now
[16:59:28 CDT(-0500)] <peterk> the states aren't ... but the mappings
[16:59:51 CDT(-0500)] <peterk> ohh, those are stored in the app def?
[16:59:53 CDT(-0500)] <EricDalquist> oh I see, the flags for even showing that chrome
[17:00:07 CDT(-0500)] <EricDalquist> the flags for even showing that chome aren't persisted anywhere yet
[17:00:18 CDT(-0500)] <peterk> ok
[17:00:28 CDT(-0500)] <EricDalquist> I think that is pending the portlet rendering attribute code that got put off
[17:00:33 CDT(-0500)] <peterk> so for that you may need a portlet-def-scoped attribute provider
[17:00:40 CDT(-0500)] <EricDalquist> perhaps it needs to get put back on
[17:00:53 CDT(-0500)] <EricDalquist> probably once we get portlet def scoped attributes figured out
[17:01:03 CDT(-0500)] <peterk> right, we put it off because we couldn't identify the need
[17:01:07 CDT(-0500)] <EricDalquist> actually ... could this state/mode filter go both before and after the structure transform?
[17:01:26 CDT(-0500)] <EricDalquist> the only thing that will affect the structure transform is WindowState=MAXIMIZED
[17:01:50 CDT(-0500)] <EricDalquist> everything else I believe is only applied after the structure
[17:02:14 CDT(-0500)] <peterk> you're trying to optimize caching ?
[17:02:20 CDT(-0500)] <EricDalquist> since the PortletModes and other WindowStates don't affect the rest of the structure of the layout, just the targeted portlet
[17:02:21 CDT(-0500)] <EricDalquist> yes
[17:02:47 CDT(-0500)] <peterk> hmm ... the buttons won't change state in accordance to the current mode ?
[17:03:13 CDT(-0500)] <EricDalquist> the buttons would, but is that done by the theme or the structure?
[17:03:22 CDT(-0500)] <peterk> theme
[17:04:00 CDT(-0500)] <peterk> yah, you could split it, but the only way to know the effect on performance is to test it
[17:04:13 CDT(-0500)] <EricDalquist> true
[17:04:40 CDT(-0500)] <EricDalquist> maybe I'll just do one for now with a comment that it may need to be split to reduce the number of structure transforms
[17:05:57 CDT(-0500)] <peterk> right
[17:06:30 CDT(-0500)] <peterk> there are a couple of filters though - one injecting portlet modes/window states, another injecting rendering attributes mapped from the portlet def (i.e. show edit button or not, etc.)
[17:06:50 CDT(-0500)] <peterk> the later should be able to work though standard rendering attribute api
[17:06:56 CDT(-0500)] <peterk> the former would have to be a custom filter
[17:07:09 CDT(-0500)] <peterk> (that we would reuse in other contexts I imagine)
[17:07:24 CDT(-0500)] <EricDalquist> right
[17:07:54 CDT(-0500)] <EricDalquist> the one I'm doing now that injects modes/stats is uP2 context specific since I'll be using rendering attribute specific to the uP2 structure and theme XSLs
[17:08:44 CDT(-0500)] <peterk> oh, right. perhaps you can make syntax part configurable
[17:09:35 CDT(-0500)] <EricDalquist> yeah
[17:09:44 CDT(-0500)] <EricDalquist> I have to go right now, I may be back on later tonight
[17:53:34 CDT(-0500)] * deuce_ (n=deuce@uni1.unicon.net) has joined ##uportal
[17:58:50 CDT(-0500)] * peterk_ (i=[U2FsdGV@66.226.77.81) has joined ##uportal
[18:19:42 CDT(-0500)] * EricDalquist (n=dalquist@76.210.61.89) has joined ##uportal
[18:26:11 CDT(-0500)] <deuce_> initportal broken?
[18:26:27 CDT(-0500)] <EricDalquist> whats the exception from?
[18:26:45 CDT(-0500)] <deuce_> java.sql.SQLException: Unique constraint violation: in statement [INSERT INTO UP_PORT_APPL_DEF (PORT_APPL_DEF_ID, PORT_APPL_DEP_ID) VALUES (?, ?)]
[18:27:46 CDT(-0500)] <EricDalquist> hrm, has data.xml changed recently?
[18:28:44 CDT(-0500)] <deuce_> i-firmaitive
[18:29:04 CDT(-0500)] <deuce_> looks like it has to do with relocating dtds
[18:29:51 CDT(-0500)] <EricDalquist> may want to touch base with shawn (I think he did the DTD work) then and see what his changes involved
[18:30:05 CDT(-0500)] <deuce_> yea
[18:34:21 CDT(-0500)] <peterk> unique constraint violation sounds like an id generation problem
[18:34:38 CDT(-0500)] <EricDalquist> probably a typo in data.xml
[18:34:52 CDT(-0500)] <EricDalquist> referencing a sequence Id that is already used by another line
[18:35:26 CDT(-0500)] <peterk> but we've also changed some id-generation items lately
[18:37:01 CDT(-0500)] <peterk> hmm .. I am not getting that exception ...let me clear the db
[18:39:20 CDT(-0500)] <peterk> deuce_: I am not seeing this problem in the head
[18:39:29 CDT(-0500)] <peterk> (using hsql)
[18:39:58 CDT(-0500)] <deuce_> ok .. must be our changes
[18:41:00 CDT(-0500)] <deuce_> i dont that we've modified anything related to sequence id generation .. hmmm
[18:41:03 CDT(-0500)] <deuce_> ^see
[18:41:07 CDT(-0500)] * peterk thinks it would be great to synch up on one repository
[18:41:17 CDT(-0500)] <deuce_> that's what i'm trying to do now
[18:42:14 CDT(-0500)] <peterk> are there two portlet defs with the same id in the data.xml?
[18:56:52 CDT(-0500)] <deuce_> dunno .. there are numerous other exceptions too
[18:57:03 CDT(-0500)] <deuce_> will begin to tackle manana
[18:57:05 CDT(-0500)] <deuce_>
[18:57:06 CDT(-0500)] <deuce_> peace
[18:57:38 CDT(-0500)] <peterk> later