18:00:51 <bleathem> #startmeeting 18:00:58 <jbott> Meeting started Sat Mar 19 18:00:51 2011 UTC. The chair is bleathem. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:58 <jbott> Useful Commands: #action #agreed #help #info #idea #link #topic. 18:01:24 <bleathem> #meetingtopic SEAMFACES-33 18:01:29 <jbossbot> jira [3SEAMFACES-33] Create a solution for consolidated page-flow, transactional control, security constraints and URL-rewriting configuration [10Open (Unresolved) Feature Request,7 Blocker,6 Brian Leathem] https://issues.jboss.org/browse/SEAMFACES-33 18:01:38 <mojavelinux> grr, here is the code that I hate 18:01:42 <mojavelinux> // Only skip to render response if there are no view parameters 18:01:47 <mojavelinux> Collection<UIViewParameter> params = 18:01:51 <mojavelinux> ViewMetadata.getViewParameters(viewRoot); 18:01:56 <mojavelinux> if (params.isEmpty()) { 18:02:01 <mojavelinux> facesContext.renderResponse(); 18:02:06 <mojavelinux> } 18:02:10 <mojavelinux> why??? 18:02:15 <mojavelinux> okay, so it's very clear that we need to hook into this 18:02:19 <mojavelinux> ViewMetadata metadata = vdl.getViewMetadata(facesContext, viewId); 18:02:23 <mojavelinux> if (metadata != null) { // perhaps it's not supported 18:02:27 <mojavelinux> // and use it to create the ViewRoot. This will have, at most 18:02:32 <mojavelinux> // the UIViewRoot and its metadata facet. 18:02:36 <mojavelinux> viewRoot = metadata.createMetadataView(facesContext); 18:02:40 <mojavelinux> vdl == view declaration language 18:02:45 <bleathem> #topic which faces event/phase to listen for, to invoke a security check 18:03:09 <mojavelinux> we are tackling a few things, first, we need to add a dummy view parameter if one doesn't exist 18:03:22 <mojavelinux> and there are any other components in the facet 18:03:37 <mojavelinux> so we need to override createMetatdataView 18:03:44 <bleathem> #info we want the security check to take place before any side effects can occur 18:03:48 <mojavelinux> so how do we register our own vdl 18:04:30 <bleathem> #info viewAction is a source of side effects 18:04:45 <mojavelinux> view-declaration-language-factory 18:05:12 <bleathem> #action we want to add a dummy view parameter programatically so that the viewAction is always called 18:06:17 <bleathem> #info We want to allow the end user to specify if security should be enforced before/after viewActions are called 18:06:32 <bleathem> #action We will need Seam Security qualifiers for this 18:06:52 <bleathem> guess I should be more clear what "this" is 18:07:20 <bleathem> #action We will need Seam Security qualifiers for enforcing security before/after viewActions are called 18:08:05 <bleathem> mojavelinux the corresponding events to listem to would be ?? and PreRenderViewEvent 18:08:15 <mojavelinux> hang on, getting to it 18:08:45 <bleathem> ok, that's what you are looking up? 18:09:17 <mojavelinux> I'm looking up how we are going to tie into this whole thing, almost there 18:10:10 <bleathem> #action implement/resurrect the PreRenderViewEventProcessor chain / SystemEventProcessor to allow sequencing of system events listeners 18:10:27 <mojavelinux> okay, I think all we need to do is override the ViewHandler 18:10:44 <bleathem> rather than listening for events? 18:10:58 <mojavelinux> which we don't yet do 18:11:03 <mojavelinux> here's the idea 18:11:19 <mojavelinux> the topic is adding a dummy UIViewParameter 18:11:25 <mojavelinux> because this is the first step in this process 18:11:30 <bleathem> #chair mojavelinux 18:11:34 <jbott> Current chairs: bleathem mojavelinux 18:11:58 <bleathem> #topic adding a dummy UIViewParameter 18:12:04 <mojavelinux> #info if we override ViewHandler, then we can return a wrapped version of the ViewDeclarationLanguage 18:12:44 <mojavelinux> #info when createMetadataView is called, we delegate to parent, then, if there are components in the view metadata, but no UIViewParameter, we add a dummy instance 18:13:21 <mojavelinux> #info we override view handler by using <view-handler> in faces-config.xml 18:13:41 <mojavelinux> we can look into other ways to do this, let's just go with this as a prototype 18:13:45 <bleathem> and createMetadataView *is* called even though ni UIViewParamter is present? 18:14:03 <mojavelinux> meaning, we could go lower and provide a custom ViewDeclarationLanguageFactory and wrap the ViewDeclarationLanguage instead 18:14:16 <mojavelinux> yes, createMetadataView is always called 18:14:22 <bleathem> ok 18:14:29 <mojavelinux> i'll reiterate the mojarra code 18:14:36 <mojavelinux> oh, info that 18:15:11 <bleathem> #info mojavelinux: we could go lower and provide a custom ViewDeclarationLanguageFactory and wrap the ViewDeclarationLanguage instead 18:15:23 <mojavelinux> #info createMetadataView is always called 18:15:27 <mojavelinux> if (vdl != null) { 18:15:31 <mojavelinux> // If we have one, get the ViewMetadata... 18:15:35 <mojavelinux> ViewMetadata metadata = vdl.getViewMetadata(facesContext, viewId); 18:15:40 <mojavelinux> if (metadata != null) { // perhaps it's not supported 18:15:44 <mojavelinux> // and use it to create the ViewRoot. This will have, at most 18:15:48 <mojavelinux> // the UIViewRoot and its metadata facet. 18:15:53 <mojavelinux> viewRoot = metadata.createMetadataView(facesContext); 18:15:58 <mojavelinux> // Only skip to render response if there are no view parameters 18:16:02 <mojavelinux> Collection<UIViewParameter> params = 18:16:06 <mojavelinux> ViewMetadata.getViewParameters(viewRoot); 18:16:11 <mojavelinux> if (params.isEmpty()) { 18:16:15 <mojavelinux> facesContext.renderResponse(); 18:16:19 <mojavelinux> } 18:16:23 <mojavelinux> } 18:16:28 <bleathem> oic, if params.isEmptuy 18:16:32 <mojavelinux> yeah, so see where we can inject our own stuff 18:16:36 <mojavelinux> is by overriding createMetadataView 18:16:41 <bleathem> yep 18:16:45 <mojavelinux> and weaving 18:16:49 * lightguard_jp is having fun going through new hire info :) 18:16:54 <mojavelinux> hehehe 18:16:58 <mojavelinux> okay, so that solves our UIViewParameter problem, I'll jira that 18:17:12 <bleathem> lightguard_jp probably the happiest paperwork you had to go through in a long time 18:17:17 <mojavelinux> #action file jira for adding dummy UIViewParameter if there are other non-UIViewParameter children in the metadata view 18:17:27 <lightguard_jp> Oh, did you start a meeting? 18:17:32 <bleathem> next topic? 18:17:37 <mojavelinux> yep 18:17:45 <mojavelinux> #topic where to hook in security restrictions 18:17:49 <bleathem> lightguard_jp ype, the IRC logs for this conversation got *really* long 18:17:56 <lightguard_jp> bleathem: Yeah, and it actually makes sense. I read the NDA and all the legal stuff and it was actually understandable. 18:18:12 <bleathem> i wonder if there is some way to delete my first topic 18:18:21 <bleathem> oh well, we can disregard it 18:18:42 <mojavelinux> #info disregard first topic on hooking in seam security in favor of subsequent info lines 18:19:23 <mojavelinux> aha! 18:19:27 <mojavelinux> idea 18:19:37 <mojavelinux> we can fire and event for post create metadata view 18:19:41 <mojavelinux> :) 18:19:47 <mojavelinux> yeah, more hooks 18:19:51 <bleathem> nice 18:20:01 <mojavelinux> so we want this one to be really nice ;) 18:20:14 <mojavelinux> okay, so we have built the view with just the ui view metadata 18:20:28 <mojavelinux> now is the best time for early security 18:21:00 <bleathem> #idea mojavelinux fire an event for post create metadata view 18:21:04 <mojavelinux> the next thing that happens in the jsf lifecycle is apply request values to the components in the metadata facet 18:21:20 <mojavelinux> I guess we could do before too :) 18:21:25 <mojavelinux> for the event 18:21:30 <mojavelinux> we'll see if that's useful 18:21:49 <mojavelinux> but these are critical points in the lifecycle, sure is nice to be able to tie into them 18:21:53 <bleathem> #action fire pre and post create-metadata-view events 18:22:51 <bleathem> so the early seam security check will be post-create-metadataview 18:23:05 <bleathem> and late seam security check will be prerenderview 18:23:20 <mojavelinux> now here's the question, do you want to transfer the view config into view metadata components at this point? 18:23:26 <mojavelinux> as though the user defined them in the template? 18:23:31 <bleathem> I would think the other way around 18:23:43 <mojavelinux> k, it's up to you, either way 18:23:55 <bleathem> I don't think we can define them in the template 18:24:01 <bleathem> one sec 18:24:22 <mojavelinux> why not? well, you could have s:restrictView for EL restrictions 18:24:27 <mojavelinux> but it would be different 18:24:39 <mojavelinux> true, okay, so you are correct, we can't have a 1-to-1 mapping 18:24:43 <mojavelinux> it will be an aggregate 18:25:09 <bleathem> "Note line 4. The page author must ensure that the <f:metadata> element does not appear on a template or included page. It must reside on the root page that corresponds to the viewId." 18:25:15 <bleathem> http://javaserverfaces.java.net/nonav/docs/2.0/pdldocs/facelets/f/metadata.html 18:25:38 <mojavelinux> yes, but you can still use templating 18:25:56 <mojavelinux> you just have to pass the <f:metadata> into a <ui:define> block 18:26:00 <mojavelinux> we do this in booking 18:26:05 <mojavelinux> and weld permalink 18:26:09 <bleathem> right 18:26:13 <mojavelinux> it's just sort of quirky 18:26:20 <bleathem> but the metadata has to be defined per page 18:26:25 <mojavelinux> and you can use ui:include inside of <f:metadata> 18:26:37 <bleathem> right, that's the trick, ui:include 18:26:41 <mojavelinux> #info you can use ui:include inside of <f:metadata> 18:26:46 <mojavelinux> you just can't do it outside 18:27:00 <mojavelinux> it's not ideal, but it can get almost the same result 18:27:08 <mojavelinux> you just have a lot of repeat ui:include blocks 18:27:18 <bleathem> boilerplate 18:27:30 <bleathem> which is where the @ViewConfig comes in nice 18:27:34 <mojavelinux> yep, though remember, we can programmatically add them 18:27:38 <mojavelinux> exactly 18:27:42 <bleathem> f:metadata for prototyping 18:27:47 <mojavelinux> we could provide view actions view @ViewConfig! 18:27:51 <mojavelinux> :) 18:27:55 <bleathem> nice 18:28:00 <mojavelinux> exactly 18:28:04 <mojavelinux> sweet 18:28:08 <bleathem> this is coming along nicely 18:28:13 <mojavelinux> very 18:28:17 <bleathem> #idea mojavelinux: we could provide view actions view @ViewConfig! 18:28:21 <mojavelinux> excellent 18:28:36 <bleathem> have we got our hook points settled? 18:28:56 <bleathem> postCreateMetadataViewEvent and PreRenderView? 18:29:16 <mojavelinux> just a sec 18:29:24 <mojavelinux> wife is talking 18:29:31 <bleathem> got it! 18:30:10 <mojavelinux> there should be a code for that ;) 18:30:31 <mojavelinux> there are two paths we can take here 18:30:38 <bleathem> Seam Security Qualifiers? 18:30:54 <mojavelinux> one path is to register a security executor component 18:31:10 <mojavelinux> as the first component in the view metadata 18:31:14 <mojavelinux> w/ immediate = true 18:31:26 <mojavelinux> and let it execute and we tie into that 18:31:50 <mojavelinux> the other approach is to tie into our own post create metadata view event 18:31:56 <mojavelinux> the only problem with events is the ordering 18:32:03 <bleathem> <s:restrictView immediate="true"> corresponds to the postCreateViewMetadataEvent 18:32:21 <mojavelinux> right 18:32:43 <mojavelinux> how I worked around this in seam servlet is this 18:32:47 <bleathem> And we would have a corresponding Seam Security qualifier for use in @ViewConfig 18:32:56 <mojavelinux> I fire two events for a lifecycle point 18:33:07 <mojavelinux> the first has an @Internal qualifier 18:33:11 <bleathem> We only need one qualifier to correspond to immediate, the default shoud be late 18:33:16 <mojavelinux> the second is a public one 18:33:25 <bleathem> ok 18:33:48 <bleathem> So we can act on an event before the end-developer can 18:33:52 <mojavelinux> I think we don't need a qualifier for the immediate , it is jsut an attribute on the security annotation 18:33:57 <mojavelinux> perhaps 18:34:02 <bleathem> ok 18:34:06 <bleathem> that's better 18:34:12 <mojavelinux> in a sense, PreRenderViewEvent is perfectly useless 18:34:19 <mojavelinux> because it's just way too late 18:34:34 <mojavelinux> however, consider this 18:34:53 <mojavelinux> the post create metadata view event isn't good either 18:34:59 <mojavelinux> because that only happens on initial request 18:35:04 <mojavelinux> useful event, but not for the purpose of security 18:35:11 <bleathem> right 18:35:16 <mojavelinux> what we really need is post-restore view 18:35:20 <bleathem> we can re-visit the view, with changed data 18:35:24 <mojavelinux> at that point, we know we have a metadata facet 18:35:37 <mojavelinux> also, we need to have a security "on-postback" flag 18:35:51 <mojavelinux> that determines if it's enforced on postback or not 18:35:56 <mojavelinux> though the default should be that it is 18:36:19 <bleathem> #idea mojavelinux: we need to have a security "on-postback" flag - that determines if it's enforced on postback or not (default true) 18:36:23 <mojavelinux> view actions are the opposite, default onPostack=false 18:36:36 <mojavelinux> because they are designed for initial requests 18:36:41 <bleathem> #info view actions are the opposite, default onPostack=false 18:36:45 <mojavelinux> security is something you always want 18:36:49 <mojavelinux> or 99% of the time 18:36:53 <bleathem> right makes sense 18:37:06 <mojavelinux> so I would tie into post-restore view phase for enforcing security 18:37:15 <bleathem> always? 18:37:29 <bleathem> what about for initial requests? 18:37:33 <mojavelinux> same 18:37:37 <mojavelinux> oh, for immediate 18:37:42 <mojavelinux> for immediate security 18:37:47 <bleathem> we won't have application data to inspect 18:37:51 <mojavelinux> for late security, PreRenderViewEvent is fine 18:37:55 <bleathem> oh, ok 18:38:12 <bleathem> Which should be default? 18:38:16 <bleathem> late? 18:38:20 <mojavelinux> early 18:38:27 <bleathem> I think most security would need to be checked against application data 18:38:44 <mojavelinux> why isn't application data available though? 18:38:49 <bleathem> which would be available early on post back 18:38:53 <mojavelinux> you are saying that things like view parameters aren't yet resolved 18:39:01 <bleathem> an initial request, post restore view 18:39:06 <bleathem> yes 18:39:10 <mojavelinux> so like what's the blog entry for instance 18:39:14 <mojavelinux> or which user are we viewing 18:39:19 <mojavelinux> got it 18:39:37 <bleathem> mabye default late for intial request, early for postback 18:39:41 <mojavelinux> okay, so early checking would be like this 18:39:48 <mojavelinux> viewId and current user session 18:39:59 <mojavelinux> like, okay, you are joe shmo and the viewId is /admin/ 18:40:04 <mojavelinux> deny 18:40:17 <bleathem> right 18:40:27 <bleathem> thtat would be an early one 18:40:39 <mojavelinux> then let's say, for PreRenderView 18:40:43 <mojavelinux> we've looked up the user 18:40:50 <mojavelinux> let's say the blog entry 18:40:54 <mojavelinux> no, let's say a document 18:40:59 <bleathem> you are joe shmo and view is /view?entry=JohnsItem 18:41:03 <mojavelinux> we get a document 18:41:07 <mojavelinux> in like a view action 18:41:17 <mojavelinux> then we see if the current user can view that document, perhaps via a rules engine or something 18:41:22 <mojavelinux> or acl 18:41:27 <mojavelinux> then deny 18:41:37 <mojavelinux> we could do security before the view actions 18:41:45 <mojavelinux> but after the view parameters, but that seems like a very rare condition 18:41:54 <mojavelinux> chances are, the view actions are pulling the application data 18:42:11 <mojavelinux> but there is another case 18:42:21 <mojavelinux> what about on postback, you clicked delete 18:42:26 <mojavelinux> you can do security in PreRenderView 18:42:30 <mojavelinux> can't 18:42:36 <mojavelinux> because the document will be gone by then :) 18:42:40 <mojavelinux> so then, you need early 18:42:50 <mojavelinux> which should be available in the application data memory 18:42:55 <mojavelinux> so then you know what we need 18:43:03 <mojavelinux> early and late needs to be per initial request or postback 18:43:08 <mojavelinux> so like this 18:43:12 <bleathem> right, I think a sensible default might be: default late for intial request, early for postback 18:43:19 <mojavelinux> initial = "late", postback="early" 18:43:26 <mojavelinux> yep, and then we can have never 18:43:33 <mojavelinux> initial = "never", postback = "early" 18:43:42 <mojavelinux> okay, idea that one 18:43:53 <bleathem> wait, what's the "never" 18:43:57 <bleathem> one? 18:45:29 <mojavelinux> dont' apply security in that case 18:45:33 <mojavelinux> I think we need 4 options 18:46:02 <bleathem> default: initial = "late", postback="early" 18:46:06 <mojavelinux> initial | postback = AFTER_RESTORE | BEFORE_INVOKE | BEFORE_RENDER 18:46:15 <bleathem> ok 18:46:25 <bleathem> that sumamrises it nicely 18:46:30 <mojavelinux> #idea timing for security enforcement is initial | postback = AFTER_RESTORE | BEFORE_INVOKE | BEFORE_RENDER 18:46:48 <mojavelinux> #idea default timing is initial = BEFORE_RENDER, postback = AFTER_RESTORE 18:46:59 <mojavelinux> or should it be postback = BEFORE_INVOKE? 18:47:17 <bleathem> for the default? 18:47:21 <mojavelinux> yeah 18:47:28 <bleathem> yeah, I think so 18:47:33 <bleathem> no side effects 18:47:37 <bleathem> but viewParams are all present 18:48:19 <mojavelinux> okay, cool, so we can fine tune all that...that's just the details 18:48:46 <bleathem> ratehr than BEFORE_RENDER, We could be AFTER_INVOKE, to make sure we get applied before other BEFORE_RENDER events 18:49:16 <mojavelinux> yeah, I think so...only trick bit is, we don't have a hook for that in jsf 18:49:21 <mojavelinux> though we could make one 18:49:25 <bleathem> #idea postback coud be BEFORE_INVOKE rather than AFTER_RESTORE - no side effects, yet viewParams are all present 18:49:29 <mojavelinux> by adding a metadata component 18:49:34 <mojavelinux> like securityenforcer 18:49:38 <bleathem> we have the after phase listener 18:49:42 <mojavelinux> duh 18:50:14 <bleathem> but that is a FINEST details :P 18:50:19 <mojavelinux> hehehe 18:50:32 <mojavelinux> okay, so I see these steps 18:50:36 <bleathem> so se have out JSF event tie-ins 18:50:48 <bleathem> what else do we need... 18:50:53 <mojavelinux> #1 create an security enforcer 18:50:58 <mojavelinux> #2 hook it into the life cycle 18:51:24 <mojavelinux> #3 override ViewMetadata and add the dummy UIViewParameter if there are any non-UIViewParameter components but no UIViewParameter 18:51:30 <mojavelinux> sorry, ViewHandler 18:51:52 <mojavelinux> override ViewHandler, to wrap ViewDeclarationLanguage to override createMetadataView 18:52:07 <mojavelinux> that will fix our UIViewAction problem too 18:52:12 <bleathem> Side note: can we get sub-tasks in the JBoss jira? 18:52:27 <bleathem> These would be good issues as sub-tasks of seamfaces-33 18:52:31 <mojavelinux> oh, we intentially disabled those because they were annoying, do you like them? 18:52:36 <mojavelinux> true 18:52:40 <mojavelinux> we just use linked issues 18:52:44 <mojavelinux> depends-on 18:52:48 <bleathem> they're annoying in that they are only 1 level deep 18:52:53 <bleathem> ok 18:52:57 <bleathem> depends on is fine 18:53:01 <mojavelinux> let's use that 18:53:26 <mojavelinux> cool! I think we are much further along now, woot 18:53:37 <bleathem> Is ViewMeta (as a replacement for ViewData) to similar in name to JSF's ViewMetadata? 18:53:46 <bleathem> yes, the path ahead is clear 18:55:26 <bleathem> The initial first pass on this was going to be to use the @Viewconfig, and add in the f:metadata tags later, possibly post 3.0 18:56:07 <bleathem> Are we still ok with this, given that our discussion was f:metadata centric? 18:57:18 <bleathem> And I think we need qualifiers rather than attributes for the timing, since the end developers create the Seam Security annotations themselves. 18:57:30 <bleathem> No qualifier present, = the default behaviour agreed to above 18:58:31 <jbossbot> git [12faces] push 10master7 6b0d9f5.. 6Dan Allen ignore faces-config dia files 18:58:35 <jbossbot> git [12faces] push 10master7 da97474.. 6Shane Bryzak [maven-release-plugin] prepare release 3.0.0.CR2 18:58:40 <jbossbot> git [12faces] push 10master7 142bb53.. 6Shane Bryzak [maven-release-plugin] prepare for next development iteration 18:58:44 <jbossbot> git [12faces] push 10master7 5ae0dcb.. 6Dan Allen Merge branch 'master' of github.com:seam/faces 18:58:48 <jbossbot> git [12faces] push 10master URL: http://github.com/seam/faces/compare/da0cc20...5ae0dcb 18:58:52 <bleathem> Then when we scan for the SeamSecurity annotations qualified with @SecurityBindingType, we can check for the timing qualifiers @BeforeInvoke, @AfterRestore, @BeforeRender 18:59:18 <jbossbot> git [12faces] push 10master URL: http://github.com/seam/faces/compare/5ae0dcb...da0cc20 18:59:24 <bleathem> #commands 18:59:28 <jbott> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #rejected #restrictlogs #save #startmeeting #topic #unchair #undo #unlurk 18:59:52 <bleathem> #info 18:59:56 <jbossbot> git [12faces] push 10master7 1f1e3d8.. 6Dan Allen ignore faces-config dia files 19:00:01 <jbossbot> git [12faces] push 10master URL: http://github.com/seam/faces/compare/da0cc20...1f1e3d8 19:00:18 <mojavelinux> sorry, screwed up that push at first 19:00:36 <mojavelinux> yep 19:01:23 <mojavelinux> the f:metadata discussion was important for context, we've determined that we can get our hooks using what's available 19:01:45 <mojavelinux> well, sort of 19:02:00 <mojavelinux> remember, without a UIViewParameter, you don't get invoke application on an initial request 19:02:25 <bleathem> but do we need that? 19:02:59 <mojavelinux> so what are the decided on hook points again? meaning what exactly will you use as the tie in (I know we discussed the available timing, but I'm looking for the actual relationships) 19:03:10 <bleathem> ok 19:03:17 <mojavelinux> so the after restore is in a phase listener? 19:03:28 <bleathem> yes 19:03:32 <mojavelinux> I suppose you can use the delegating phase listener 19:03:40 <bleathem> before render could be either phase or system 19:03:45 <mojavelinux> to launch it, like w/ the transactions 19:03:58 <bleathem> yes, then you get the injection 19:04:19 <mojavelinux> I think the system event is probably best for pre-render 19:04:30 <bleathem> BEFORE_INVOKE would be skipped on initial request, if there were no viewAction 19:05:08 <mojavelinux> true, let's just say that for now you need a view action for security to be called at that point on intiial request 19:05:14 <bleathem> general curiosity, why is the system event prefered over the phase listener? 19:05:25 <bleathem> ok 19:05:29 <mojavelinux> and the view action is current dependent on a view parameter (which we will fix either before or after 3.0) 19:05:43 <bleathem> in essence, BEFORE_INVOKE is meaningless if you have no action to invoke 19:05:48 <mojavelinux> right 19:05:54 <bleathem> I'd like to see that fixed before 3.0 19:06:06 <bleathem> it'll get lots of questions/complaints in the forum 19:06:11 <mojavelinux> I can probably take that one...I think I know what needs to be done 19:06:17 <bleathem> that'd be good 19:06:29 <mojavelinux> we really need jsfunit tests, that's something which we may not have time for though 19:06:37 <bleathem> ok, does that wrap it up? I'll file some jiras, and we're good to go? 19:06:42 <mojavelinux> but a lot of this testing is manual w/o it 19:06:46 <mojavelinux> yep 19:06:53 <bleathem> Don't get me started on the need for JSFUnit tests 19:07:00 <mojavelinux> as for the system event vs phase for prerender 19:07:05 <bleathem> we'll be here another 3 hours! 19:07:33 <mojavelinux> it's hard to say, probably the same really 19:07:42 <mojavelinux> just more fine-grained if you do system 19:07:46 <bleathem> one more question: should the Qualifiers we spoke about be Seam Security qualifiers, or Faces Qualifiers? 19:07:51 <mojavelinux> because you know that you don't interfere with application phase listeners 19:07:59 <mojavelinux> faces 19:08:08 <bleathem> ok 19:08:20 <mojavelinux> you might just be able to use what you have, as in @Before @Render 19:08:40 <mojavelinux> @Before @RenderResponse 19:08:50 <mojavelinux> only downside is that you might think you can use any combination 19:08:54 <bleathem> Then we might get people trying unsupported combinations 19:08:58 <mojavelinux> but you could fail at startup 19:09:08 * bleathem is a slower typer than mojavelinux 19:09:12 <mojavelinux> when processing the enum 19:09:35 <mojavelinux> you could also just say that the timing is assumed 19:09:40 <mojavelinux> and then just do @RenderResponse 19:10:00 <mojavelinux> they tell you which phase, the timing within the phase is fixed 19:10:10 <bleathem> We could ignore unsupported qualifiers, assume the default, and log an error 19:10:22 <mojavelinux> fail is better 19:10:27 <mojavelinux> it's like having a bad injection point 19:10:37 <bleathem> ok 19:10:43 <bleathem> how do I do that? 19:10:51 <bleathem> Is there another class I can look at for an example? 19:11:42 <mojavelinux> the view config extension currently has the code for processing the enum 19:11:49 <mojavelinux> it does isAnnotationPresent 19:11:56 <mojavelinux> you would want to do getAnnotations() 19:12:03 <bleathem> #idea use the exisitng Faces qualifiers to qualify the Seam Security annotations (eg. @RenderResponse_ 19:12:10 <mojavelinux> and make sure that only the allowed phases are there 19:13:09 <mojavelinux> I would play with some ideas in the jira comments about how it will look for the user 19:13:15 <bleathem> ok, is that done at application startup? 19:13:29 <bleathem> the allowed phases stuff 19:13:36 <bleathem> or when the @ViewConfig is processed 19:13:49 <bleathem> nevermind 19:13:56 <mojavelinux> yep 19:14:03 <bleathem> getting confused with f:metadat which is processed on first visit 19:14:10 <mojavelinux> btw, are you going to change @ViewData to @ViewPattern? 19:14:20 <mojavelinux> @ViewPattern("/admin/*") 19:14:24 <bleathem> I changed ViewData to VeiwMeta 19:14:29 <bleathem> oh wait 19:14:33 <mojavelinux> ah, right 19:14:37 <bleathem> let me check 19:14:42 <mojavelinux> actually, you know what 19:14:46 <mojavelinux> you should do 19:15:07 <bleathem> yeah, I'd done ViewMeta 19:15:11 <bleathem> but I'm not married to it 19:15:15 <mojavelinux> @ViewMeta(patterns = {"/admin/*", "/admin.xhtml"}) 19:15:20 <kenfinnigan> mojavelinux: You fixed SOLDER-86 as part of SOLDER-85 didn't you? 19:15:24 <jbossbot> jira [3SOLDER-86] Split up LoggerProducers [10Open (Unresolved) Task,7 Minor,6 Ken Finnigan] https://issues.jboss.org/browse/SOLDER-86 19:15:28 <jbossbot> jira [3SOLDER-85] Better separation of i18n and logging concerns [10Resolved (Done) Enhancement,7 Major,6 Dan Allen] https://issues.jboss.org/browse/SOLDER-85 19:15:33 <mojavelinux> yep! 19:15:37 <kenfinnigan> cool, will mark it done 19:15:45 <mojavelinux> or perhaps @ViewMeta(viewIds = {}) 19:16:05 <mojavelinux> what if you do 19:16:09 <bleathem> What other parameter would go in ViewMeta, that would warrant adding a parameter name? 19:16:33 <bleathem> How about @ViewIds() 19:16:37 <bleathem> ? 19:17:06 <mojavelinux> ah, in that case, you probably want @ViewPattern 19:17:18 <bleathem> Ok, I'll go with @ViewPattern 19:17:27 <bleathem> but the rest should stay as @ViewMeta I think 19:17:32 <mojavelinux> and you can do @ViewPatterns({@ViewPattern("/admin/*"), @ViewPattern("/admin.xhtml")}) 19:17:36 <bleathem> It's bigger than just ViewPattern 19:17:44 <bleathem> nice 19:17:53 <mojavelinux> the thing is, each enum value is the meta 19:17:58 <bleathem> #topic Naming convention 19:18:02 <mojavelinux> so the annotation can't be ViewMeta 19:18:06 <mojavelinux> because then that means everything is in that one annotation 19:18:11 <mojavelinux> when in fact, it's stacked 19:18:19 <bleathem> #idea rename @ViewMeta to @ViewPattern 19:18:29 <mojavelinux> or ViewMapping 19:18:34 <bleathem> #idea, one can suport @ViewPatterns({@ViewPattern("/admin/*"), @ViewPattern("/admin.xhtml")}) 19:18:41 <bleathem> View mapping is good too 19:18:57 <bleathem> but I like the pattern part to support the "*" 19:19:18 <johnament_away> so if you have an admin section of your app, you always secure it 19:19:23 <mojavelinux> right, the value is a collection of patterns 19:19:47 <bleathem> ok, I'll end the meeting then, and create some jiras. 19:19:51 <mojavelinux> @ViewMapping({"/admin/*", "/admin.xhtml"}) 19:20:19 <bleathem> I don't feel strongly about either, if you have a preference 19:20:28 <mojavelinux> not really, we can see what the masses thing 19:20:32 <mojavelinux> think 19:20:55 <mojavelinux> btw, internally, ViewMetadata is fine 19:21:00 <bleathem> #idea or maybe instead @ViewMapping({"/admin/*", "/admin.xhtml"}) 19:21:07 <bleathem> rather than ViewMeta? 19:21:11 <mojavelinux> in a sense, this is a superset, or complement to template view metadata 19:21:25 <mojavelinux> so it's really a very similar purpose 19:21:29 <bleathem> If they are indeed analagous, then ViewMeatadata is better 19:21:44 <bleathem> I'll go with ViewMetadata then 19:21:48 <mojavelinux> I would say it's either ViewMetadata or ViewConfiguration 19:21:52 <mojavelinux> cool 19:21:59 <bleathem> ViewMetadataStore 19:22:12 <bleathem> ViewConfiguration sounds to similar to Viewconfig 19:22:39 <mojavelinux> yep, though honestly I wouldn't mind @ViewConfiguration 19:22:44 <bleathem> Or we could use ViewConfigStore 19:22:55 <bleathem> Since it is storing the ViewConfig 19:23:03 <bleathem> rahter then ViewmetaDataStore 19:23:22 <bleathem> ^rather than ViewMetadataStore 19:23:26 <mojavelinux> I like the Store suffix for the holder 19:23:31 <mojavelinux> that works 19:24:57 <mojavelinux> we could do @ViewMetadata, but hard to pluralize that 19:25:10 <bleathem> #action renamve @ViewMeta to @ViewMapping 19:25:25 <bleathem> #action rename @ViewMetaStore to @ViewConfigStore 19:25:38 <mojavelinux> i know, we are saying that the view configuration associates metadata with various views 19:25:55 <bleathem> ok, I got myself all turned around. 19:26:11 <bleathem> I'll mess around with the naming in code, and come up with something that captures the intent nicely 19:26:21 <mojavelinux> wait, ViewConfigStore isn't an annotation 19:26:25 <mojavelinux> is it? 19:26:29 <mojavelinux> it's just like this 19:26:33 <bleathem> No, it's not 19:26:38 <bleathem> I cpoy and paster the previous line 19:26:47 <bleathem> copy and paste alway intorduces error :P 19:27:02 <bleathem> my typing is going downhill altogether at the moment 19:27:13 <bleathem> #closemeeting 19:27:25 <bleathem> #endmeeting